Vacuum Sensing questions

[David Griffiths]

I have just got around to connecting my vacuum pressure sensor and I am confused by the results I am seeing.

This is the graph I am seeing on the Nozzle Tip Part Detection pane. Firstly I am pretty sure the blue trace for Valve is not showing the actual valve in use. I increased the pump on delay time and I could see the delay in the graph and the log showed the valve opening later but the graph didn't.

I don't understand what the graph is showing. Why the two steps?

What values should I be setting for Vacuum Range?

It might be nice if the graph also showed the Z height so you can better relate the timing of the graph.

This graph is 100% repeatable.

My sensor is located in the head just before the two valves for the two nozzles. This example is showing a single pick on one nozzle. Using Smoothieboard and Thermocouple input 1.

My config files and log are here:

https://www.dropbox.com/sh/7pikr9028w2wnpw/AAAjCQmYHycENeHlBdoXxwsYa?dl=0

TIA,

DG

[mark maker]

> Firstly I am pretty sure the blue trace for Valve is not showing the actual valve in use. I increased the pump on delay time and I could see the delay in the graph and the log showed the valve opening later but the graph didn't.

That's true, it records the request for valve actuation, not the actual actuation, so if it has to wait for the pump to start up, this delay is not shown. This is admittedly confusing and could be fixed quite easily.

The graph was not intended to create a veritable "machine history". It is only about how the vacuum sensor signal behaves after the valve actuation was requested. The goal here is to distinguish between when the part is nicely picked, i.e. creating a good vacuum seal, and when it is not. The graph can give you feed-back as to what happens there, and typically, only the end of the graph is relevant, i.e., "does the vacuum level rise to the right value in time?". The idea is to experiment with successful picks and to provoke ones that aren't, like with an empty feeder, then set the "good range" to discriminate between the two.

> I don't understand what the graph is showing. Why the two steps?

If you look into your log, you see these are the vacuum readings as reported by your controller. They match exactly what the graph plots over time.

There is the pump startup delay between the first and the second measurement, and the graph simply draws a straight line between the two, which is obviously a simplification.

But from then on, the vacuum readings are continuous and at high rate (2ms, ~500Hz). But your controller seems to read the ADC only every 50ms (20Hz) and then just reports the same value over and over again, which creates the steps in the graph. It is probably tuned for 3D printing where the measured temperatures cannot fluctuate that much over time. You have a smoothie controller, so you can change that polling interval on the controller side. There is a readings_per_second setting, on my machine it is at 320 (don't remember where that came from).

> It might be nice if the graph also showed the Z height so you can better relate the timing of the graph.

Yes that would be nice, but not so easy, because (again) what we know is when we request the nozzle to move in Z, we do not really know when it will really move, and we do not want to add unnecessary "wait for completion" requests to know when it is done, because they disrupt the whole optimized asynchronous driver parallelism. Nowadays we could probably ask the Motion Planner what it predicted the Z to be at the current time, which is reasonably accurate on a Smoothie or Duet. That stuff wasn't around back when I first developed the vacuum sensing. 😉

https://makr.zone/openpnp-advanced-vacuum-sensing-part-on-part-off-detect/421/

I will keep these improvements in mind... or anybody is welcome to contribute 😁

_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/b95c42dc-0e98-4d9f-b9f2-c9c2439cde69n%40googlegroups.com.

[David Griffiths]

Thank you Mark.  Your response was enlightening as usual. I will experiment further.

DG

[David Griffiths]

My Smoothie config did not have a readings_per_second entry but I found where to add it and it now samples at 2mS. :-) 

It looks like this for anyone interested:

#######################################################
#      Uses temperature functions for Vacuum Pump     #
#         i.e., Using the thermistor input to         #
#                 read vacuum levels                  #
#######################################################

## Temperature control configuration
# See http://smoothieware.org/temperaturecontrol

# First vacPump configuration
temperature_control.vacPump.enable              true          # Whether to activate this ( "hotend" ) module at all.
temperature_control.vacPump.thermistor_pin      0.23          # Pin for the thermistor to read
temperature_control.vacPump.readings_per_second 500              # ADC samples per second
#temperature_control.vacPump.heater_pin         1.23          # Pin that controls the Vacuum Pump
temperature_control.vacPump.thermistor          EPCOS100K     # See http://smoothieware.org/temperaturecontrol#toc5
#temperature_control.vacPump.set_m_code         104           # M-code to set the temperature for this module
#temperature_control.vacPump.set_and_wait_m_code 109          # M-code to set-and-wait for this module
temperature_control.vacPump.designator          T             # Designator letter for this module-reads as T0 in response to
                                                              #                  M105 command

> That's true, it records the request for valve actuation, not the actual actuation, so if it has to wait for the pump to start up, this delay is not shown. This is admittedly confusing and could be fixed quite easily.

It is confusing but also useless because from what I can see it will always be shown turning on at time zero.

My graphs now look very different, but I am still confused at what they are telling me. One thing I have realised is that my vacuum system is not as well sealed as I thought, but it seems the pump is big enough to overcome the losses.

The biggest problem I have is correlating the graph to actual events. eg the graph always shows an elbow about half way along - is this when the valve actually opens??

Some suggestions:

- would it be possible to add a timestamp to the graph so you can look at exactly the right place in the log?

- adding dots where actual samples occur to distinguish point to point lines from actual samples

- would it be possible to extract data for the graph from the log file? Then you would have actual valve open times and Z movements.

- and a side note, I find the axis values on all graphs hard to read - they need to be a darker shade of grey

- a function to generate a graph on demand for some predefined period would be useful for testing valve operation, leakage etc  Otherwise I might need to get the scope out ;-)

So here are three graphs showing in order, Pick OK with pump already running, failed pick pump already on and successful pick with pump not already running.

I did get part detection to work but I have no confidence it would be reliable and I haven't even tried picking on two nozzles.

My files are here:

https://www.dropbox.com/sh/7pikr9028w2wnpw/AAAjCQmYHycENeHlBdoXxwsYa?dl=0

Comments please. What are these graphs showing?  I am using Juki nozzle tips (503 in these graphs). Could the elbow be where the Z lifts and reduces any spring pressure on the part?

BTW Mark, I love the Camera Freeze Settings feature :-)  My cameras not infrequently come up missing and then have the wrong settings.

[mark maker]

> It is confusing but also useless because from what I can see it will always be shown turning on at time zero.

It is not useless in the PartOff graph. And both graphs are made the same way for consistency.

https://github.com/openpnp/openpnp/wiki/Setup-and-Calibration_Vacuum-Sensing#valve-openclose-time

> The biggest problem I have is correlating the graph to actual events.

I already agreed that this could be improved. For now just take that "elbow" as the actual  valve actuation.

You also have to take into account that many of us keep the pump running for better speed and vacuum stabilty, and then the "pump wait" confusion resolves itself:

https://github.com/openpnp/openpnp/wiki/Setup-and-Calibration_Vacuum-Setup#pump-control-setup

I for one run the pump on a hysteresis, based on a vacuum reservoir pressure:

https://makr.zone/vacuum-sensor/192/

> adding dots where actual samples occur to distinguish point to point lines from actual samples

That's actually a graph feature Tony added later, I agree it would be useful here.

> a function to generate a graph on demand for some predefined period would be useful for testing valve operation, leakage etc  Otherwise I might need to get the scope out ;-)

Unfortunately not that easy to to. I believe Smoothie has a periodic reporting feature.

The other suggestions I think are better addressed by revamping vacuum sensing stuff a bit. Once Z axis and valve are better indicated, much of the mystery is gone.

> and a side note, I find the axis values on all graphs hard to read - they need to be a darker shade of grey

You should probably look at your monitor's gamma or contrast setting. And use the mouse hovering feature for earnest readings.

Feel free to contribute!

_Mark

On 10.02.2023 23:53, David Griffiths wrote:

My Smoothie config did not have a readings_per_second entry but I found where to add it and it now samples at 2mS. :-) 

It looks like this for anyone interested:YOu hve o be a bit

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/cfe4de87-026b-48e7-b82e-67f681eb18ccn%40googlegroups.com.

[David Griffiths]

I am still trying (unsuccessfully) to get my head around what I am seeing in these graphs.

Here is a successful pick with the pump already running.

Here is an extract from the log:

2023-02-13 13:33:18.872 ReferenceNozzle DEBUG: NR.pick()
2023-02-13 13:33:18.874 GcodeAsyncDriver DEBUG: serial://COM4 commandQueue.offer(M204 S545.29 G1 X390.2576 Y253.6139  A-178.9724  F10299.13 ; move to target, 30000)...
2023-02-13 13:33:18.876 GcodeAsyncDriver DEBUG: serial://COM4 commandQueue.offer(M204 S6.75 G1  Y253.7036    F600.00 ; move to target, 30000)...
2023-02-13 13:33:18.878 GcodeAsyncDriver DEBUG: serial://COM4 commandQueue.offer(M204 S1130.61 G1   Z-20.0000   F6988.74 ; move to target, 30000)...
2023-02-13 13:33:18.882 GcodeAsyncDriver DEBUG: serial://COM4 commandQueue.offer(M400 ; Wait for moves to complete before returning, 39474)...
2023-02-13 13:33:18.882 GcodeAsyncDriver DEBUG: serial://COM4 commandQueue.offer(M114 ; get position, -1)...
2023-02-13 13:33:19.845 GcodeAsyncDriver DEBUG: serial://COM4 commandQueue.offer(M105 ;read all vacuum sensors, 30000)...
2023-02-13 13:33:19.846 ReferenceActuator DEBUG: AVACS1.read(): 120.4
2023-02-13 13:33:19.848 ReferenceActuator DEBUG: Pump.actuate(true)  [pump already running - manually initiated]
2023-02-13 13:33:19.848 GcodeAsyncDriver DEBUG: serial://COM4 commandQueue.offer(M108, 30000)...
2023-02-13 13:33:19.900 ReferenceActuator DEBUG: AVAC1.actuate(true)
2023-02-13 13:33:19.900 GcodeAsyncDriver DEBUG: serial://COM4 commandQueue.offer(M110, 30000)...
2023-02-13 13:33:19.952 GcodeAsyncDriver DEBUG: serial://COM4 commandQueue.offer(M105 ;read all vacuum sensors, 30000)...
2023-02-13 13:33:19.960 ReferenceActuator DEBUG: AVACS1.read(): 101.2
2023-02-13 13:33:19.961 GcodeAsyncDriver DEBUG: serial://COM4 commandQueue.offer(M105 ;read all vacuum sensors, 30000)...
2023-02-13 13:33:19.962 ReferenceActuator DEBUG: AVACS1.read(): 99.9  [first reading that is within configured vacuum range so it raises Z]
2023-02-13 13:33:19.963 AbstractHeadMountable DEBUG: NR.moveToSafeZ(0.76)
2023-02-13 13:33:19.963 AbstractHeadMountable DEBUG: NR.moveTo((403.412560, 201.943764, -7.500000, -178.972448 mm), 0.76)
2023-02-13 13:33:19.966 GcodeAsyncDriver DEBUG: serial://COM4 commandQueue.offer(M204 S1146.10 G1   Z-7.5000   F7181.55 ; move to target, 30000)...
2023-02-13 13:33:19.967 GcodeAsyncDriver DEBUG: serial://COM4 commandQueue.offer(M400 ; Wait for moves to complete before returning, 39474)...
2023-02-13 13:33:19.967 GcodeAsyncDriver DEBUG: serial://COM4 commandQueue.offer(M114 ; get position, -1)...
2023-02-13 13:33:20.179 GcodeAsyncDriver DEBUG: serial://COM4 commandQueue.offer(M105 ;read all vacuum sensors, 30000)...
2023-02-13 13:33:20.180 ReferenceActuator DEBUG: AVACS1.read(): 90.9
2023-02-13 13:33:20.183 AbstractMachine TRACE: Machine entering idle state.

I am presuming the graph starts at 19.846 where the first read of the pressure sensor occurs. 120.4 is what I see when the pump is running and valve is closed.

The pump actuator is operated immediately after this read, but it was already running. 

Then 52mS later the valve is actuated. I do not have a pump start delay configured, so where does this delay come from?

Pick dwell is configured for 100mS.

The actuator commands are confirmed in the log about 1 or 2mS after being sent.

Then another 52mS later it starts polling every 2mS for the pressure readings.  Again, where is this delay coming from?

There is 116mS from the first reading to the elbow in the graph, where the reading is 99.9 (in the range) at which point the nozzle is raised.

If there was another pressure read when the valve is actuated, I think I would see the graph flat at 120 till this point and then and even steeper decline to the elbow.

So it seems that what I am seeing overall is a fairly rapid decline in the vacuum from when the valve is operated and then the rate of decline slows significantly when the nozzle is raised. This doesn't make a lot of sense.

I don't see how I can set parameters to detect the part with this wavefor. The failed pick graph looks very similar.

Full log and other files are here:

https://www.dropbox.com/sh/7pikr9028w2wnpw/AAAjCQmYHycENeHlBdoXxwsYa?dl=0

[mark maker]

Just a wild guess:

Pick dwell times are defined in two places: for nozzles (fora a basic wait) and nozzle tips (for a nozzle tip specific wait). They are summed together.

Maybe you oversaw one or the other.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/b50b5278-a4ef-46ee-ba6b-7f9c47423ce7n%40googlegroups.com.

[David Griffiths]

I don't have any Pick Dwell configured on the smaller nozzle tips. The 100mS is on the nozzle. 

I tried doubling the dwell time and it didn't change the graph. 

DG 

[mark maker]

It is a strange log extract. I don't see any controller responses.

Curious that the next actuation equally takes 52ms. Almost as if the controller takes that long.

Please send a whole unaltered, unfiltered log at TRACE level. Best send one of the past 100 log files that OpenPnP keeps in the log subdirectory.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/bc6daeef-0165-4f58-a8d1-92e709c3ee18n%40googlegroups.com.

[David Griffiths]

The full log file is at the Dropbox link in previous post. 

Cheers DG 

[mark maker]

I've looked at the OpenPnP code, which is not very complex, and the only way I can explain it, is that Java or the OS interferes.

Even if you specify 0ms for pump delay and/or pick dwell, the thread will go asleep, which means the OS scheduler will potentially select other threads for running first, i.e. it might take much longer than "0ms" for our thread to be scheduled again (granularity). If your PC is otherwise loaded, or has an older/cheap/thermally constrained/energy saving CPU with fewer cores (that might already struggle with decoding two quality web cam MJPEG streams), the effect might be more prominent.

https://www.javamex.com/tutorials/threads/sleep.shtml

In my own (Windows) experience, I would expect a typical 15ms scheduling granularity, but in your case the granularity seems to be ~50ms, as I see it happen consistently, four times in the log.

That's all interesting as a computer science issue, but quite irrelevant in practical terms. It will always take much more than 50ms for a vacuum switch to become effective. And you can still use your vacuum graph for diagnostics, as only the right-hand part matters, where the measured level reaches and stays in its good range, or not.

Note, the graph extends to the check events you selected, so there may also be individual Alignment (if you aligned) and Before Place measurements. I already agreed, it would be nice to mark the measurements with a dot.

Having said that, I will keep the Thread.sleep() shortcomings in mind for any revision.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/6b925f6e-01e5-48b8-8213-16f3ab310a75n%40googlegroups.com.