Duet Openpnp Head

[wayneosdias]

I've built a custom Duet Exp3 board using the Duet SAME5x that handles x3 motors, the limits and the outputs. The only thing missing is x2 vacuum analog sensing and I don't think I'll be able to use the Duet control algorithm as the analog/heat task is only 4Hz. There is also some vac based logic processing that needs to take place and I'd like to keep the Duet focused on digital signals and kinematics.

My solution is to use a secondary vacuum sensor board with a dedicated non-Duet mcu to monitor sensor levels and that will set digital io on the Duet inputs. Sensor thresholds will be dynamically set via Openpnp/Duet Aux comm via RS485. Openpnp will simply ask the state of the associated Duet input...

Am I over complicating this? Am I missing a fully native Duet solution?

Current Duet based machine

New Duet based machine, Vacumm sensor board in question

Any input appreciated

[dc42]

@wayneosdias you may be able to do the vacuum processing on the same processor and send the result over CAN.

The InputHandles module can take analog inputs and report back to the main board when the reading passes a threshold. See function CommonAnalogInterrupt in https://github.com/Duet3D/Duet3Expansion/blob/3.6-dev/src/InputMonitors/InputMonitor.cpp You could modify it to change the conditon for reporting back. Just be careful not to flood the CAN bus constantly with messages.

Perhaps you can do the necessary processing and only report back when a significant change occurs?

Another way would be to create a dummy output port, such that writing to that port using M42 triggers that module to send that input back.

It's hard for me to give more specific advice without knowing how you use the vacuum sensors.

[wayneosdias]

@dc42
Your Duet solution sounds interesting, but bus loading sounds like a potential issue and I don't have the know how to analyze any performance hits to the CAN bus. I do appreciate your answer though as it reinforces my confidence in my work around.

The rationale for vacuum sensing to determine whether a part was successfully 'picked' or not. Vacuum sensing is not mandatory, and I have been running without it for sometime, but it can substantially increase machine efficiency. Efficiency is increased by not allowing the machine to run every potential pick to the vision system 100's mm away.

As you note, Openpnp doesn't necc need to know the actual vacuum value, but whether a part is 'on' or 'off' the nozzle. The challenge in qualifying if a part is 'on' vs 'off' include;

• Different nozzle tips have different vacuum 'on', but part 'off' values
• Different part packages have different 'on' values for the same tip
• The vacuum signal in general is very noisy and slow to build to maximum.

Openpnp has some pretty comprehensive functions to analyze and differentiate vacuum states for all vacuum part/tip parameters. But my machine initially had weak diaphragm pump that was slow and noisy. I couldn't get the Openpnp functions to work consistently in a practical way. I've since upgraded to vacuum ejectors, and I no longer have any of the original control electronics.

Im all Duet3 now with robust pneumatics, I'm pretty confident I could use Duet3 Temp/analog sensing to leverage the Openpnp functions. But this seems like it will be slow especially given the Duet 4Hz sampling rate. This is a full custom system now and I think a purpose-built vacuum sensor feedback system would be much quicker. I don't want to slow the system by packing dwells into the pick/feed process waiting for a stable Temp reading.

This is all just speculation. I don't have the sensor circuit designed or in place yet. I have no idea what the sensor hw actual transfer fxn will look like and or if it'll need filering.

Regardless of the vacuum sensing hw, I like the idea of abstracting the Openpnp fxns and performing them locally on a dedicated vac board mcu. The mcu is updated on the current part/nozzle via Duet3 aux comm and allowed to free run sampling the sensors, only flagging the Duet/Openpnp system via IO_x.in on any state changes.

[dc42]

@wayneosdias the 4Hz sampling rate only applies to the rate at which data from sensors (configured using M307) is collected and returned from the expansion board to the main board; and to the collection of data from sensors connected to the main board into the object model. The actual sampling in the ADC is much faster on both main boards and expansion boards. Changes to digital inputs are also signalled from expansion boards to the main board very quickly. Likewise when an analog input configures as general purpose input crosses the threshold value.

So it's entirely possible to do the processing you want on your custom expansion board and pass it back to the main board over CAN.

OTOH if you need the data to be passed directly into the Pi (or other computer running OpenPnP) then that would be a reason for bypassing the expansion board processor and CAN and using a separate cable back to the Pi.