ventionco / mm-python-api Goto Github PK

When instantiating the MachineMotion object, I noticed an issue while using certain methods. It seems like there needs to be some delay added to properly initialize the object.

For example if I were to check if the IO expander is available (if connected to the controller) using isIoExpanderAvailable() without a delay, it will output false. If I add a 1 second delay (time.sleep(1)) in between and call the method again it will return true as expected:

code:

output:

I presume that it takes some time for for the object to initialize. We should add a delay right after the instantiation of the MachineMotion object.

MMv2, SW 2.4
in mm-config in Cloud9, statement "kill_python_apps_on_estop" is True (software and hardware reboot was performed)

When the modified example estop.py was run, Estop was triggered mid sequence, the script then continued where it left off even though it should not after the callback function was executed.

See image

We're using machine motion SDK to control a robot that takes pictures of pots in a greenhouse and we're having some trouble on a new computer. We had everything working but now whenever we run mm.resetSystem() we've gotten 2 different errors.

1. No connection could not be made because the target machine actively refused it
   

2. Exception: System is still not ready after 10.0 seconds
   

It's also successfully gotten past the mm.resetSystem() but only occasionally and without rhyme or reason. Any ideas on how to debug this would be incredible because we're needing pictures from the robot ASAP.

Thanks!

[ ] compare configHomingSpeed
[ ] Switch back MQTT
[ ] Switch back to a single file
[ ] _MachineMotion.py
[ ] remove configWizard
[ ] removeEncoderDistance
[ ] change emitSetAxisDirection - configAxisDirection

The new move() method works as intended I believe.

As for the new eStop functions, I'm getting stuck in a infinite loop when trying to use them. Here is the console log whenever I try to call any of them:

Code(with debug comments):

Console:

It gets stuck when calling MQTTsubscribe.simple(); loops indefinitely.

Originally posted by @mohitpatel-vention in https://github.com/VentionCo/mm-vention-control/issues/476#issuecomment-572286567

readEncoder() returns a variable saved to the mm object.
When mm is initialized, it initializes this variable to zero.
This variable is updated once mqtt publishes to the encoder topic.
Therefore, if the client tries to readEncoder before the encoder topic has been published to, it will wrongly return a value of 0. 0 represents the unitiliazed object rather than the actual encoder value

This can be fixed using "subscribe_simple" and asking for retained messages