Safety Checks before Motion

470 views
Skip to first unread message

ma...@makr.zone

unread,
Nov 3, 2020, 9:51:45 AM11/3/20
to OpenPnP
Hi everybody

Marek and I have started a discussion about his machine's safety check of the Z axis (pneumatic) to be up before motion in X/Y is allowed. It turned out that he is using a sub-driver/Gcode "hack" that will no longer be supported in axis centric Motion Control.

(we should not hijack this thread, so let's continue here).

There was a similar question in the DesktopPnP group for a sensor on a drag pin on the CHMT36VA:


So I think this is a valid demand for a more general solution.

How would we do that?

I see a common ground in the actuator that is used.
  1. In the pneumatic nozzles scenario it is the actuator used to lift or lower the Z axis.
  2. In the drag pin scenario it is the actuator of the drag pin.
  3. In both scenarios the actuator can be stuck it seems and it is therefore necessary for it to be backed by a confirmation sensor.
  4. It seems the confirmation can not be made a part of the actuation itself (the controller checking the confirmation) for some reason or other.
  5. Plus it is probably the intention to exclude user error too: you should never move in X/Y if the actuator is still physically down/engaged.
  6. Therefore, the sensor(s) should always be checked before moving in X/Y.
  7. There can be many sensors per head (multiple nozzles, a drag pin and more). 
  8. Therefore, it might make sense to create a subclass InterlockActuator, that could do that.
  9. You could add as many InterlockActuators to the head as you like.
  10. All the InterlockActuators would be evaluated before the head can be moved in X or Y.
  11. The InterlockActuator could be a boolean actuator that times out or fails with COMMAND_ERROR_REGEX when the confirmation sensor does not confirm the good state in due time.
  12. The InterlockActuator could be a double actuator to read a sensor value and compare it to a legal range. Otherwise, operation is halted (Exception).
What do you think?

_Mark

Marek T.

unread,
Nov 3, 2020, 10:00:36 AM11/3/20
to OpenPnP
Hi Mark,

For me it sounds as should do.

BTW: I didn't know it is some hack. I was convinced it is normal operation for the drivers tree working: the same command is possible to assign to every drivers and it is executed one-by-one after the previous one was regex confirmed. So it is generally not working this way, or only for the move_to_command? I wonder whether this "hack" removing is problem for the motions only or some other operations as well.

ma...@makr.zone

unread,
Nov 3, 2020, 10:34:22 AM11/3/20
to ope...@googlegroups.com

Hi Marek

> I didn't know it is some hack. I was convinced it is normal operation for the drivers tree working: the same command is possible to assign to every drivers and it is executed one-by-one after the previous one was regex confirmed.

This was already broken in OpenPnP 2.0 before I started my Advanced Motion Control. With the introduction of MOVE_TO_COMPLETE_COMMAND the move and the wait for completion was split up and execution already overlapping between main driver and the (first) sub-driver.

https://github.com/openpnp/openpnp/wiki/GcodeDriver%3A-Command-Reference#move_to_complete_command

And that is what 99.9% of users that have axes on different controllers want: they don't want the second controller to have to wait for the first one to complete! There were videos on YouTube where you saw how the nozzle rotation had to painfully wait for the X, Y to complete: yawn!

Whether it was a "hack" or not is of course open for debate. In my book the fact that this got broken by a legitimate extension like MOVE_TO_COMPLETE_COMMAND rather favors a "yes" ;-)

_Mark

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/82161bd1-586d-4f7d-96ea-892940ae6308o%40googlegroups.com.

Marek T.

unread,
Nov 3, 2020, 10:46:56 AM11/3/20
to OpenPnP
Let it be that "yes" :-).

Frankly speaking I have forgotten about MOVE_TO_COMPLETE...
On some day I have made a machine.xml for 2.0 for my machine, mainly to test your tools for vacuum and video analyze only, and surprisely it has even worked :-).
So I must look there I have done this with the MOVES, maybe I have ignored sensor checking as it was created for the basic test only.
To unsubscribe from this group and stop receiving emails from it, send an email to ope...@googlegroups.com.

ma...@makr.zone

unread,
Nov 6, 2020, 1:53:43 PM11/6/20
to ope...@googlegroups.com

Hi everybody

See the Wiki for the new InterlockActuator. Any feedback is very welcome!

https://github.com/openpnp/openpnp/wiki/Interlock-Actuator

@Marek, this will also replace your MarekNozzle. See the Pneumatic Nozzle Example.

https://github.com/openpnp/openpnp/wiki/Interlock-Actuator#pneumatic-nozzles

The implementation is done, but it still needs machine testing.

_Mark

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/244ff205-446d-451e-9b32-3cc231adc7cfo%40googlegroups.com.

Jason von Nieda

unread,
Nov 6, 2020, 2:34:10 PM11/6/20
to ope...@googlegroups.com
Hey Mark - this is really awesome work. I think this will solve a huge number of use cases for people! But, I do have a thought:

This seems to put a lot of unrelated functionality all inside a single actuator, and sort of changes an actuator from a basic read/write device to a very "smart" device. It also means that new functionality will further complicate this one (seemingly) large actuator. Would it be cleaner to implement these features closer to where they live and instead just assign one of the basic actuators to it? For instance, the check if Z is up could be on the axis or nozzle, and you would assign an actuator there. The check for machine movement would likewise be on an axis, etc.

The reason I think this is important is that, if I understand correctly, this actuator goes straight to the driver which means people cannot use a ScriptActuator or an HttpActuator for any of these functions, and must instead use a driver directly. I think it's important that we maintain the generic functionality of actuators so that things like ScriptActuator are still useful, and we can add other implementations later.

Just something to consider - I do think this is a massively powerful and helpful feature!

Thanks,
Jason


To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/2317970a-df40-ee35-10df-586edaa05b00%40makr.zone.

Marek T.

unread,
Nov 6, 2020, 5:18:08 PM11/6/20
to OpenPnP
Hi Mark!

So I need to download and run the test version, isn't it?

The questions:
- Pneumatic Nozzles
"Then create the InterlockActuator shown here to actuate the pneumatic valve to physically move as soon as the virtual axis reaches its Safe Z coordinate"
So an Actuator will be actuated_on when SafeZ is reached, nozzle commanded to be raised up.
What about lowering the nozzle? Is this actuator set actuate_off whenever Z is set manually (jog with arrows) or systemable to value < than SafeZ?
So if I presse ArrowDown one time (no matter the value 0.1 or 1 etc) - nozzle goes down. If press second time - nothing happens. To raise the nozzle I must press ArrowUp (once or more) until the Z is >SafeZ, right?

- Safety Confirmation Sensor
I'm not sure what means "Confirmation Range -3" on the wiki picture sample and how I should configure it, as you know in my case I'm waiting for <ok> only. So should I just ignore this parameter?
To unsubscribe from this group and stop receiving emails from it, send an email to ope...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ope...@googlegroups.com.

ma...@makr.zone

unread,
Nov 7, 2020, 4:44:45 AM11/7/20
to ope...@googlegroups.com

Hi Jason

I understand. I'll try to explain my choices, then discuss alternatives.

> sort of changes an actuator from a basic read/write device to a very "smart" device

From a user's perspective, I don't see how this in itself  should be problematic. I see no particular reason why an Actuator must remain dumb while an Axis may become smart. ;-) The InterlockActuator is a sub-class, so other Actuators will not be burdened by any smartness (nor the accompanying complexity).  But I do see the technical problem of the implementation (see below).

> Would it be cleaner to implement these features closer to where they live and instead just assign one of the basic actuators to it? For instance, the check if Z is up could be on the axis or nozzle, and you would assign an actuator there. The check for machine movement would likewise be on an axis, etc.

Two problems there:

  1. The interlock may concern more than one axis. See the examples where the motion of X, Y, C should be inhibited by one interlocking condition. A user would have to duplicate the configuration of exactly the same interlocking condition on each of these axes.
  2. The same axis can have multiple interlocking condition: a machine might have a "nozzle is up" sensor on each of its multiple nozzles. Another machine might have both a nozzle sensor(s)  and a drag pin sensor, and/or a safety door sensor. We need to guard against illegal X, Y etc. movement for all of them. Doing all this on the axis would require some sort of complex 1:N GUI.
> The reason I think this is important is that, if I understand correctly, this actuator goes straight to the driver which means people cannot use a ScriptActuator or an HttpActuator for any of these functions, and must instead use a driver directly. I think it's important that we maintain the generic functionality of actuators so that things like ScriptActuator are still useful, and we can add other implementations later.

Yes, the old single inheritance trap (one of the reasons why I wrote my own MDA/4GL/OOP language for our products :-)).

In a single inheritance design, this would have to be a third object, hanging in a N:M relationship between axes and actuators. However, in a hierarchy such as the Machine Setup these sort of "cobweb" objects are a bit cumbersome to place and handle.

Proposal: rather than as a sub-class, I could implement this as a sub-component of the Actuator.  A separate "smart" object, acting as a Monitor for the then-again "dumb" actuator.

I would then move the interlockType up into the AbstractActuator. As long as it is set to "None" (default), nothing else happens. As soon as you choose another type (and press Apply), it will instantiate the sub-component - let's call it InterlockActuatorMonitor - and wire it to the actuator. A new Wizard Tab will appear with the Monitor's config. This way we can assign the InterlockActuatorMonitor to any of the Actuator sub-classes.

This would be much like the ReferenceNozzleTipCalibration which is also a separate object for more or less the same reason, I guess.

Note: This will be more or less transparent to the user. The user would still think of this as one object, as in case of the nozzle tip calibration. So the Actuator being "smart" could still be a problem, if there is a deeper reason to reject that.

_Mark

ma...@makr.zone

unread,
Nov 7, 2020, 4:59:45 AM11/7/20
to ope...@googlegroups.com

> So I need to download and run the test version, isn't it?

Not yet! Like I wrote, I still need to test this on my machine and Jason has also voiced some concerns that probably requires some changes.

> What about lowering the nozzle?

Oh, yeah I rewrote it to make it clearer. Please reread ;-)

https://github.com/openpnp/openpnp/wiki/Interlock-Actuator#pneumatic-nozzles

> - Safety Confirmation Sensor
> I'm not sure what means "Confirmation Range -3" on the wiki picture sample and how I should configure it, as you know in my case I'm waiting for <ok> only. So should I just ignore this parameter?

In your case you would use the Confirm Match Before Axes Move.

Then use an ACTUATOR_READ_REGEX that simply matches the "ok" of your special controller. This will timeout in OpenPnP in case of failure.

I guess I don't need to tell you that this is not a particularly stable design. It would of course be better, if your special controller were to monitor both the valve command and the "nozzle is up" sensor, and then based on an internal timeout for how long the valve command is allowed to take to be executed and reflect in the sensor, respond with a definitive reading "0" or "1".

;-)

_Mark
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/a6c43043-d5d8-47a8-9a2b-3e8a3848c1dco%40googlegroups.com.

Marek Twarowski

unread,
Nov 7, 2020, 5:47:20 AM11/7/20
to ope...@googlegroups.com
Hi Mark,

Ok, so waiting for your signal when something is ready to test :-).

Everything is rather clear for me on the moment. 
With one small exception that natural position of the Nozzle is just SafeZ level when the actuator is just off. And when it's actuated we need to set it On (to lower the Nozzle down) not otherwise. But it's matter of the logic only, or naming, ir proper code assignnent :-).

ma...@makr.zone

unread,
Nov 7, 2020, 6:13:51 AM11/7/20
to ope...@googlegroups.com

> With one small exception that natural position of the Nozzle is just SafeZ level when the actuator is just off. And when it's actuated we need to set it On (to lower the Nozzle down) not otherwise. But it's matter of the logic only, or naming, ir proper code assignnent :-).

There is another type Signal Axes Outside Safe Zone that inverts the logic.

https://github.com/openpnp/openpnp/wiki/Interlock-Actuator#interlock-actuation

And of course you could also invert the logic using swapped G-code in {True} and {False}

Or you could invert the controller's pin polarity.

http://smoothieware.org/pin-configuration

_Mark

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

Nélio Oliveira

unread,
Nov 7, 2020, 6:55:38 AM11/7/20
to OpenPnP
This seems like the solution for the current biggest problem in my CHMT36VA, the drag pin getting stuck.
I really look forward to the test version of this.
OpenPnP is getting better and better! 
Awesome work Mark! 

Marek Twarowski

unread,
Nov 7, 2020, 7:03:03 AM11/7/20
to ope...@googlegroups.com
Sure Mark, it's not big deal of course.

You received this message because you are subscribed to a topic in the Google Groups "OpenPnP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/CQX0uDciXp8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/2953ddff-4749-1063-1e59-4b31b3260680%40makr.zone.

Jason von Nieda

unread,
Nov 7, 2020, 12:50:37 PM11/7/20
to ope...@googlegroups.com
I think your proposal sounds great Mark!

Thanks,
Jason


ma...@makr.zone

unread,
Nov 8, 2020, 8:03:24 AM11/8/20
to ope...@googlegroups.com

Hi all

this is now reworked in code and Wiki:

https://github.com/openpnp/openpnp/wiki/Axis-Interlock-Actuator

It will be part of the new Update 6  & Testing Version. Coming soon.

_Mark

Marek T.

unread,
Nov 8, 2020, 10:45:54 AM11/8/20
to OpenPnP
Have you tested it on your machine?
To unsubscribe from this group and stop receiving emails from it, send an email to ope...@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ope...@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ope...@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ope...@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ope...@googlegroups.com.

ma...@makr.zone

unread,
Nov 8, 2020, 11:05:45 AM11/8/20
to ope...@googlegroups.com

Hi Marek

yes, as far as I can. I don't have a pneumatic nozzle ;-)

I just simulated it an looked at the log.

_Mark

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/d01b1156-3968-418d-9890-86fe6e466176o%40googlegroups.com.

Marek T.

unread,
Nov 8, 2020, 12:36:44 PM11/8/20
to OpenPnP
Hi Mark,

Yes, I've meant the simulation mainly.
Although you could connect any relay/valve pretending the nozzle ;) what makes no sense of course.

ma...@makr.zone

unread,
Nov 11, 2020, 2:50:27 AM11/11/20
to ope...@googlegroups.com

_Mark


Am 07.11.2020 um 18:50 schrieb Jason von Nieda:

Nélio Oliveira

unread,
Nov 12, 2020, 3:24:59 PM11/12/20
to OpenPnP
Hi, just wanted to share a video of my CHMT36VA with the latest test version of OpenPnP.
I'm really appreciated by all effort in putting together such software, specially the latest actuator interlock which allows me to properly use the drag feeders in this machine.

ma...@makr.zone

unread,
Nov 13, 2020, 3:05:26 AM11/13/20
to ope...@googlegroups.com

Thanks for sharing that!

How is this speed compared to the original CHMT36VA software/firmware?

_Mark

Nélio Oliveira

unread,
Nov 13, 2020, 6:07:25 AM11/13/20
to ope...@googlegroups.com
The speed for the job in the video is around 1000 cph and the original was around 2000 if I remember correctly.

The overall movement of the original software is more fluid. I think that there are a few things happening "at same time" and with OpenPnP you can more easily identify individual movements.

In some parts of the head movement I can see the vacuum valves activating and deactivating for a split second, that alone consumes a few milliseconds. Also the nozzles move slightly up and down. I think it has something to do with the safety Z but not sure.
Maybe I'm doing something wrong in the configuration that is causing this behavior.


Cumprimentos | Best regards
Nélio Oliveira


You received this message because you are subscribed to a topic in the Google Groups "OpenPnP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/CQX0uDciXp8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/e0b2eeea-8dbc-f951-f8dd-ae682d42cd27%40makr.zone.

cri...@gmail.com

unread,
Dec 30, 2020, 5:08:50 PM12/30/20
to OpenPnP
You said, "the nozzles move slightly up and down."  Is this happening for you when the part is over the upward looking camera? 

I wonder if it does this slight movement to put the bottom of the part at the focal point of the camera so that tall and short parts are both in optimal focus over the camera.

Nélio Oliveira

unread,
Dec 30, 2020, 5:18:42 PM12/30/20
to ope...@googlegroups.com
It does it right before moving to a new location but not everytime. I think it has to do with some verifications that the software does but not sure.

I never checked wether it moves the nozzle to the optimal position when above the camera but I have it at Z=0 anyway.
I'm not using really tall parts and did readjusted the focal point of the camera so it has been fine so far.



Cumprimentos | Best regards,

Nélio Oliveira

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/4616db64-2b12-4917-b61d-12336b498d4fn%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages