Vacuum turning off early on part placement

[Jim Young]

I have a stock LitePlacer. I'm testing the placement of parts with OpenPnP and I've run into a bit of a problem. The part of picked from the feeder and checked with the bottom camera and moved over to its placement on the board. As the nozzle is lowering to place the part the vacuum turns off before the part touches the board. This is causing the part to fall, rather than be placed, causing a misplaced part. 

I've looked all over the UI for a setting for when the vacuum is to be turned off during placement. Does this have something to do with the Place Dwell Time? I tried adjusting that but no joy.

[mark maker]

Either you switched off the default machine coordination Before Actuation switch on the Actuator...

https://github.com/openpnp/openpnp/wiki/Motion-Planner#actuator-machine-coordination

... or you re-used the actuator as a contact probe (you would not be the first one to confuse these two):

https://github.com/openpnp/openpnp/wiki/Contact-Probing-Nozzle

_Mark

On 21.04.22 19:58, Jim Young wrote:

I have a stock LitePlacer. I'm testing the placement of parts with OpenPnP and I've run into a bit of a problem. The part of picked from the feeder and checked with the bottom camera and moved over to its placement on the board. As the nozzle is lowering to place the part the vacuum turns off before the part touches the board. This is causing the part to fall, rather than be placed, causing a misplaced part. 

I've looked all over the UI for a setting for when the vacuum is to be turned off during placement. Does this have something to do with the Place Dwell Time? I tried adjusting that but no joy.

--
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/e2992cb8-c7d0-49a3-931a-d510912ae218n%40googlegroups.com.

[Jim Young]

Do you mean the ContactProbeActuator? All the actuators on the system have Before Actuation checked.

Here's the configuration for the contact probing:

[mark maker]

I just saw that you actually included the machine.xml in the OP, good!

It seems to be a a contact probe problem. You seem to have an extremely large probe offset of 13 mm and probe depth of 23 mm!

And I guess the probing does not work correctly, i.e. it seems to immediately trigger. Maybe the probe switch is not configured right (polarity?).

Note also, that the  direction of Z changes between the Liteplacer Software and OpenPnP:

OpenPnP uses the standard right-handed Cartesian coordinate system (Z axis is pointing up), while the Liteplacer uses a non-standard left-handed  coordinate system (Z is pointing down). This means that the motor polarity and end-switches are swapped. Other users needed to swap some wires and some config ... I don't remember exactly what.

@Liteplacer users please help.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/ed989c20-1896-4db3-ae09-04005aabc600n%40googlegroups.com.

[tonyl...@gmail.com]

Yes, the Z limit switches need to be swapped and the polarity of the Z axis motor needs to be reversed ($3po=1 in the TinyG configuration).

[Jim Young]

Regarding the Z axis, I've done all that. I have a jumper that switches the Z limit switch logic and I'm sending $3po=1 with my CONNECT_COMMAND. Otherwise none of the other operations would work. I can change nozzles and pick a part. It's the placement I'm having trouble with.

[Jim Young]

After giving the wiki a close reading I adjusted the probing offset and depth to more reasonable values, offset of 1 probe of 2. The vacuum is still turning off just before the part lands on the board, thought it's not as bad as it was when I first started working on this problem.

[mark maker]

I looked at your log in the OP and it seems that probing is set up correctly but it stops too early.

It stops at Z:-35.7512. It says

probed part R0603-267k height at offset -4.394mm

This seems too much for a 0603 resistor.

It seems that the switch is triggered before the nozzle tip/part actually hits the PCB. Maybe there is a mechanical obstruction, or an electrical glitch? Are your end-stop lines shielded or at least twisted-paired?

_Mark

2022-04-21 10:35:01.271 GcodeAsyncDriver$WriterThread TRACE: [serial://COM4] >> G38.2Z-50F540; probe down in absolute coordinates until limit switch is hit
2022-04-21 10:35:01.286 GcodeDriver$ReaderThread TRACE: [serial://COM4] << tinyg [mm] ok>
2022-04-21 10:35:01.286 GcodeDriver$ReaderThread TRACE: [serial://COM4] << qr:32, qi:2, qo:2
2022-04-21 10:35:01.286 GcodeDriver TRACE: [serial://COM4] confirmed G38.2Z-50F540; probe down in absolute coordinates until limit switch is hit
2022-04-21 10:35:01.286 GcodeDriver$ReaderThread TRACE: [serial://COM4] << qr:31, qi:1, qo:0
2022-04-21 10:35:01.287 GcodeAsyncDriver$WriterThread TRACE: [serial://COM4] >> M400; wait until machine has stopped
2022-04-21 10:35:03.351 GcodeDriver$ReaderThread TRACE: [serial://COM4] << qr:32, qi:1, qo:1
2022-04-21 10:35:03.351 GcodeDriver$ReaderThread TRACE: [serial://COM4] << tinyg [mm] ok>
2022-04-21 10:35:03.351 GcodeDriver TRACE: [serial://COM4] confirmed M400; wait until machine has stopped
2022-04-21 10:35:03.351 GcodeAsyncDriver$WriterThread TRACE: [serial://COM4] >> M400; Wait for moves to complete before returning
2022-04-21 10:35:03.367 GcodeDriver$ReaderThread TRACE: [serial://COM4] << tinyg [mm] ok>
2022-04-21 10:35:03.367 GcodeDriver TRACE: [serial://COM4] confirmed M400; Wait for moves to complete before returning
2022-04-21 10:35:03.368 GcodeAsyncDriver$WriterThread TRACE: [serial://COM4] >> M114; get position
2022-04-21 10:35:03.391 GcodeDriver$ReaderThread TRACE: [serial://COM4] << X:101.3892 Y:58.4699 Z:-35.7512 A:-89.5993 B:0.0000 C:0.0000
2022-04-21 10:35:03.391 GcodeDriver TRACE: Position report: X:101.3892 Y:58.4699 Z:-35.7512 A:-89.5993 B:0.0000 C:0.0000
2022-04-21 10:35:03.391 GcodeDriver$ReaderThread TRACE: [serial://COM4] << tinyg [mm] ok>
2022-04-21 10:35:03.391 GcodeDriver TRACE: GcodeDriver got lastReportedLocation (x:101.389200, y:58.469900, Z:-35.751200, A:-89.599300)
2022-04-21 10:35:03.391 GcodeAsyncDriver TRACE: GcodeDriver confirmation complete.
2022-04-21 10:35:03.391 AbstractMotionPlanner DEBUG: Reported location changes current location from (x:101.389163, y:58.469907, Z:-18.356900, A:-89.599299) to (x:101.389200, y:58.469900, Z:-35.751200, A:-89.599300)
2022-04-21 10:35:03.391 AbstractHeadMountable DEBUG: N.moveTo((15.874718, 55.367441, -34.944300, -89.599300 mm), 1.0)
2022-04-21 10:35:03.391 ContactProbeNozzle TRACE: N.toHeadLocation((15.874718, 55.367441, -35.751200, -89.599300 mm), ...) Z offset 0.807mm
2022-04-21 10:35:03.391 ContactProbeNozzle DEBUG: Nozzle N probed part R0603-267k height at offset -4.394mm

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/db1f036b-90c2-4a21-99f3-c1b2105ceff5n%40googlegroups.com.

[Jim Young]

Thanks for your reply!

Mechanically or electrically, I can see nothing wrong with the machine. I'm uploading a video that clearly shows the vacuum turning off long before the bottom limit switch is triggered.

In the pick operation the vacuum actuators are operating normally.

https://youtube.com/shorts/DTuHMB2a_nY?feature=share

[Jim Young]

I also attached a multimeter in continuity mode on limit switch wiring, right at the TinyG. There is no signal getting to the controller before the vacuum goes off. A signal is only sent when the switch is actuated. 

[bert shivaan]

Sorry if this is a dumb question, But are you sure the vac is turning off when the part falls?

In other words could it be that the vac turned off some time before that, but it didn't let go until you see it fall?

--
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/163a6452-9216-43c0-bb09-d8abd746c6a4n%40googlegroups.com.

[mark maker]

I see some things that I think you should improve i.e. that I've done differently on my Liteplacer. Note, I'm not sure they're actually related to the problem at hand, but you should sort this out first.

1. First, realize that the uncompressed/unloaded nozzle tip underside should be the true Z reference. When the nozzle column and/or the nozzle tip holder springs are compressed, the Z is actually farther down.
   
2. We want the uncompressed/unloaded true Z because we want to be able to do things such as capturing the precise height of surfaces, or pushing BlindsFeeder covers sideways etc.
   https://youtu.be/dGde59Iv6eY?t=382
   There are also feeders that must not be pressed hard on pick.
3. Consequently, the probing/limit switch should be pre-tensioned, so the practical least amount of pressure triggers it (while still otherwise remaining robustly off). The switch lever will always already press on the pulley. I slightly bent the switch lever end so it does not scratch in reverse rotation. When the switch triggers, there should be only very little compression/travel in the nozzle column. Unfortunately, it is hard to seen in this video of my Liteplacer (switch lever touching the pulley is hidden behind the rod). Best play at 0.25x:
   https://youtu.be/9uFxV1-vnXw
   
4. Once the switch triggers, you should move the nozzle up in tiny steps until the nozzle tip is only very slightly pressing on the surface to measure the Final Adjustment distance. This way the nozzle will retract after the probing, to almost the true Z we talked about above (there should still be contact).
   https://github.com/openpnp/openpnp/wiki/Contact-Probing-Nozzle#contact-sense-method
5. If I'm not mistaken, your nozzle tip is not loaded all the way. Make sure the black sleeve is pressed all the way to the hilt. This is very important to get repeatable Z. Takes a bit of force the first few times until the o-rings are trimmed (mine actually shed a bit of rubber). Loading is also in the same Video:
   https://youtu.be/9uFxV1-vnXw
6. I don't know why the pump actuator goes off early. This is certainly not visible in the log (see excerpt below), we see all the right order, including a 2 second probing wait time. It simply can't be OpenPnP's fault. Perhaps you used a TinyG IO that is somehow intrinsically tied to Z probing and switches off automatically? Perhaps other TinyG users can help?
   

_Mark

022-04-21 10:19:53.415 GcodeAsyncDriver DEBUG: serial://COM4 commandQueue.offer(G38.2 Z-50.0 F540.0 ; probe down in absolute coordinates until limit switch is hit, 1800000)...
2022-04-21 10:19:53.415 GcodeAsyncDriver DEBUG: serial://COM4 commandQueue.offer(M400            ; wait until machine has stopped, 1800000)...
2022-04-21 10:19:53.415 GcodeDriver TRACE: [serial://COM4] confirmed M114; get position
2022-04-21 10:19:53.415 GcodeAsyncDriver DEBUG: serial://COM4 commandQueue.offer(M400 ; Wait for moves to complete before returning, 1800000)...
2022-04-21 10:19:53.416 GcodeAsyncDriver DEBUG: serial://COM4 commandQueue.offer(M114 ; get position, -1)...
2022-04-21 10:19:53.416 GcodeAsyncDriver$WriterThread TRACE: [serial://COM4] >> G38.2Z-50F540; probe down in absolute coordinates until limit switch is hit
2022-04-21 10:19:53.428 GcodeDriver$ReaderThread TRACE: [serial://COM4] << tinyg [mm] ok>
2022-04-21 10:19:53.428 GcodeDriver TRACE: [serial://COM4] confirmed G38.2Z-50F540; probe down in absolute coordinates until limit switch is hit
2022-04-21 10:19:53.428 GcodeDriver$ReaderThread TRACE: [serial://COM4] << qr:32, qi:2, qo:2
2022-04-21 10:19:53.429 GcodeDriver$ReaderThread TRACE: [serial://COM4] << qr:31, qi:1, qo:0
2022-04-21 10:19:53.429 GcodeAsyncDriver$WriterThread TRACE: [serial://COM4] >> M400; wait until machine has stopped
2022-04-21 10:19:55.493 GcodeDriver$ReaderThread TRACE: [serial://COM4] << qr:32, qi:1, qo:1
2022-04-21 10:19:55.493 GcodeDriver$ReaderThread TRACE: [serial://COM4] << tinyg [mm] ok>
2022-04-21 10:19:55.493 GcodeDriver TRACE: [serial://COM4] confirmed M400; wait until machine has stopped
2022-04-21 10:19:55.494 GcodeAsyncDriver$WriterThread TRACE: [serial://COM4] >> M400; Wait for moves to complete before returning
2022-04-21 10:19:55.509 GcodeDriver$ReaderThread TRACE: [serial://COM4] << tinyg [mm] ok>
2022-04-21 10:19:55.509 GcodeDriver TRACE: [serial://COM4] confirmed M400; Wait for moves to complete before returning
2022-04-21 10:19:55.510 GcodeAsyncDriver$WriterThread TRACE: [serial://COM4] >> M114; get position
2022-04-21 10:19:55.532 GcodeDriver$ReaderThread TRACE: [serial://COM4] << X:101.7638 Y:59.0841 Z:-35.7512 A:-59.7864 B:0.0000 C:0.0000
2022-04-21 10:19:55.532 GcodeDriver TRACE: Position report: X:101.7638 Y:59.0841 Z:-35.7512 A:-59.7864 B:0.0000 C:0.0000
2022-04-21 10:19:55.533 GcodeDriver$ReaderThread TRACE: [serial://COM4] << tinyg [mm] ok>
2022-04-21 10:19:55.533 GcodeDriver TRACE: GcodeDriver got lastReportedLocation (x:101.763800, y:59.084100, Z:-35.751200, A:-59.786400)
2022-04-21 10:19:55.533 GcodeAsyncDriver TRACE: GcodeDriver confirmation complete.
2022-04-21 10:19:55.533 AbstractMotionPlanner DEBUG: Reported location changes current location from (x:101.763791, y:59.084081, Z:-18.356900, A:-59.786434) to (x:101.763800, y:59.084100, Z:-35.751200, A:-59.786400)
2022-04-21 10:19:55.533 AbstractHeadMountable DEBUG: N.moveTo((16.249318, 55.981641, -34.944300, -59.786400 mm), 1.0)
2022-04-21 10:19:55.533 ContactProbeNozzle TRACE: N.toHeadLocation((16.249318, 55.981641, -35.751200, -59.786400 mm), ...) Z offset 0.807mm
2022-04-21 10:19:55.534 ContactProbeNozzle DEBUG: Nozzle N probed part R0603-267k height at offset -4.394mm
2022-04-21 10:19:55.534 ReferenceActuator DEBUG: ContactProbeActuator.actuate(false)
2022-04-21 10:19:55.534 GcodeAsyncDriver DEBUG: serial://COM4 commandQueue.offer(M400 ; Wait for moves to complete before returning, 1800000)...
2022-04-21 10:19:55.534 GcodeAsyncDriver DEBUG: serial://COM4 commandQueue.offer(M114 ; get position, -1)...
2022-04-21 10:19:55.534 GcodeDriver TRACE: [serial://COM4] confirmed M114; get position
2022-04-21 10:19:55.535 GcodeAsyncDriver$WriterThread TRACE: [serial://COM4] >> M400; Wait for moves to complete before returning
2022-04-21 10:19:55.548 GcodeDriver$ReaderThread TRACE: [serial://COM4] << tinyg [mm] ok>
2022-04-21 10:19:55.548 GcodeDriver TRACE: [serial://COM4] confirmed M400; Wait for moves to complete before returning
2022-04-21 10:19:55.549 GcodeAsyncDriver$WriterThread TRACE: [serial://COM4] >> M114; get position
2022-04-21 10:19:55.573 GcodeDriver$ReaderThread TRACE: [serial://COM4] << X:101.7638 Y:59.0841 Z:-35.7512 A:-59.7864 B:0.0000 C:0.0000
2022-04-21 10:19:55.573 GcodeDriver TRACE: Position report: X:101.7638 Y:59.0841 Z:-35.7512 A:-59.7864 B:0.0000 C:0.0000
2022-04-21 10:19:55.573 GcodeDriver$ReaderThread TRACE: [serial://COM4] << tinyg [mm] ok>
2022-04-21 10:19:55.573 GcodeDriver TRACE: GcodeDriver got lastReportedLocation (x:101.763800, y:59.084100, Z:-35.751200, A:-59.786400)
2022-04-21 10:19:55.573 GcodeAsyncDriver TRACE: GcodeDriver confirmation complete.
2022-04-21 10:19:55.573 Scripting TRACE: Scripting.on Nozzle.AfterPlaceProbe
2022-04-21 10:19:55.574 ReferenceNozzle DEBUG: N.place()
2022-04-21 10:19:55.574 Scripting TRACE: Scripting.on Nozzle.BeforePlace
2022-04-21 10:19:55.574 ReferenceActuator DEBUG: VACUUM_SWITCH.actuate(false)
2022-04-21 10:19:55.574 GcodeAsyncDriver DEBUG: serial://COM4 commandQueue.offer(M9, 1800000)...
2022-04-21 10:19:55.574 GcodeDriver TRACE: [serial://COM4] confirmed M114; get position
2022-04-21 10:19:55.574 ReferenceActuator DEBUG: AVAC.actuate(false)
2022-04-21 10:19:55.574 GcodeAsyncDriver DEBUG: serial://COM4 commandQueue.offer(M5, 1800000)...
2022-04-21 10:19:55.574 GcodeAsyncDriver$WriterThread TRACE: [serial://COM4] >> M9

--
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/5dd6e41e-d022-4aeb-aea8-0abc038a9901n%40googlegroups.com.

[Jim Young]

Thanks, Mark

I'll work on all your suggestions. One question, what is the false parameter in the actuator call?

VACUUM_SWITCH.actuate(false)

[mark maker]

it means "off".

https://en.wikipedia.org/wiki/Boolean_data_type

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/cae27327-1ca3-46ba-879d-9c4169c6a424n%40googlegroups.com.

[tonyl...@gmail.com]

Something else I think I noticed.  This line in the log:

2022-04-21 10:19:55.533 AbstractMotionPlanner DEBUG: Reported location changes current location from (x:101.763791, y:59.084081, Z:-18.356900, A:-59.786434) to (x:101.763800, y:59.084100, Z:-35.751200, A:-59.786400)

indicates that it probed downward by 35.7512 - 18.3569 = 17.3943mm.

But from watching the video, it sure doesn't look like it moves that far.  If you watch carefully you can see the nozzle first get lowered to -18.3569, pause briefly, and then it lowers at slower speed until the switch is hit (I'm assuming the actual probe cycle after the pause).  I may be wrong but it sure doesn't look like the Z-axis moves nearly that far before the switch is hit.  Have you verified that your Z-axis scaling is correct?

Tony

[Jim Young]

How do I check the Z scaling? I checked the Wiki and I don't see anywhere to calibrate that axis.

[tonyl...@gmail.com]

First dump your TinyG settings (send $$ via the console) and verify these two settings:

$3sa=1.800

$3tr=8.0000

Then place an object of a known thickness (measure it with calipers) on your table and carefully lower the nozzle tip down until it is just barely touching it.  Record the Z value from the DRO.  Then remove the object and lower the nozzle tip until it is just touching the table. The difference between the current DRO Z value and the previous one should match the thickness of the object.

Tony

[Jim Young]

My controller values, 3sa and 3tr are the same.

I did the measurement and there is about a 7% difference between the thickness of the object I measured and travel of the probe. Of course this is all subject to my eyesight and observation.

I adjusted the probing offsets as Mark described and it's behaving better now. The vacuum shuts off just before the part is placed. 

Another possibly related question - What are Pick Dwell and Place Dwell used for? They are briefly mentioned in the wiki but other than that I could not find any detail about what they do.

[mark maker]

I agree it does not look like -17mm. Look at the edge of the camera holder vs. the rotation motor plate.

Strange.

@tonyluken, am I right to assume that you are using contact probing in pick/place? And you do not have this problem? Could you two compare notes on used IOs, config, etc?

> Another possibly related question - What are Pick Dwell and Place Dwell used for? They are briefly mentioned in the wiki but other than that I could not find any detail about what they do.The just wait for that amount of time, in order for the vacuum to build (on pick) or to dissipate (on placement):

https://github.com/openpnp/openpnp/wiki/Setup-and-Calibration%3A-Vacuum-Sensing#dwell-times--establish-level

This is just the "dumb" variant. If you have vacuum sensors, please read and understand in the context of the whole Wiki page:

https://github.com/openpnp/openpnp/wiki/Setup-and-Calibration%3A-Vacuum-Sensing

This might also be useful:

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

Note: you cannot resolve the probing problem we are taking about with these dwell times. These come after actuating the valve/pump, i.e. too late.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/a0ed055c-e05a-47fd-9375-6c5fd9104abfn%40googlegroups.com.

[tonyl...@gmail.com]

Could your Z axis motor be missing steps?  That would explain why it takes more commanded motion to travel the shorted distance.  Maybe you need to adjust the Z axis pot on the TinyG to increase the current a bit.

Tony

[Jim Young]

I boosted the current a little bit on the Z driver. No difference. I'm attaching the settings dump from my TinyG. 

With a closer inspection I am also noticing that when performing a pick, the vacuum does not turn on until right after the nozzle starts to lift from the part. This does not seem right either. I would expect the vacuum to start running as soon as the contact is detected.

Could this all have something to do with using the async driver?

[Jim Young]

Also the wiring for the MOSFET that controls the vacuum motor is the stock Liteplacer wiring, connected to the Spin connector on the TinyG.

[mark maker]

> Could this all have something to do with using the async driver?

Theoretically yes, especially if the machine coordination was not configured right, but as I said before, the log shows that everything is done in the right order, and it also correctly waits for the probing to complete (2 second time gap in the log).

So this can be excluded with a high degree of confidence.

I assume you already tried these actuators by hand, right?

https://github.com/openpnp/openpnp/wiki/Setup-and-Calibration%3A-Actuators#actuator-control-panel

They do work immediately and as long as you leave them on, right?

And just to check: your PSU is strong enough? Have you ever scoped it? Just asking, because it seems that the pump stops about the same time that the Z motor has to struggle against the spring loading, and a PSU drooping would also explain the missing -17 mm.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/3f299f62-7ac1-4af8-abfe-6f80798e677dn%40googlegroups.com.

[Jim Young]

Yes, the actuators work, the pump start immediately and stays on. 

The PSU is a Meanwell LRS-150 24, rated at 6.5 amps. It was one that was recommended by Juha from LitePlacer (it's the one he uses). I ran the pump while doing a homing operation, it never cut off. There seems to be plenty of power.

One thing I have discovered - If I turn the vacuum on manually and then do a contact probe calibration, as soon as the probing starts (I can tell because the downward motion slows) the pump shuts off. So, it appears the pump is being turned off as soon as probing begins. I'll upload a video that demonstrates this.

[tonyl...@gmail.com]

Ok, I've never actually used probing when a part was on the nozzle tip.  I just tried it and can confirm that sending g38.2 (the probe command) causes my vacuum pump to also shut-off.  I took a quick look at the TinyG code and found this in cycle_probing.c:

   // probe in absolute machine coords
   pb.saved_coord_system = cm_get_coord_system(ACTIVE_MODEL); //cm.gm.coord_system;
   pb.saved_distance_mode = cm_get_distance_mode(ACTIVE_MODEL); //cm.gm.distance_mode;
   cm_set_distance_mode(ABSOLUTE_MODE);
   cm_set_coord_system(ABSOLUTE_COORDS);

   cm_spindle_control(SPINDLE_OFF);

   return (_set_pb_func(_probing_start));                            // start the move

I believe that expains it, LitePlacer connects the vacuum pump control to the spindle pin of the TinyG.  I've got to run right now, I 'm not sure if there is another pin available for this or not.

Tony 

[Jim Young]

So now what do I do? If there was another pin to use would I just need to change the actuator command?

Here's the video of the pump turning off while doing a probe calibration.

https://youtu.be/Y0E095CJ4RM

[Jim Young]

By reconfiguring my probing offsets, I think I have part placement working reasonably well. I set the offset to zero, so that probing starts when the tip contacts the part. Now I am seeing the vacuum turn off right when the part is placed on the board. Now I'm seeing the importance of having all your part heights correctly entered. This was never a problem with the LitePlacer software, I think because it did it's own probing detection in the PC software. I say this because in LitePlacer the vacuum never turned off when part were being placed. 

[mark maker]

> I just tried it and can confirm that sending g38.2 (the probe command) causes my vacuum pump to also shut-off.  I took a quick look at the TinyG code and found this in cycle_probing.c

Thanks Tony for figuring this out. I actually had a look too, but somehow I must have missed it. 😭

I wondered WTH this is not an issue in the original Liteplacer software. In the firmware I traced it back in git (blame) and it seems to have been added in 2014-01-17. I didn't think the Liteplacer sold TinyG boards are shipped with even older firmware.

Then I looked at the Liteplacer software:

https://github.com/jkuusama/LitePlacer-DEV/blob/0607c29c5cca4654fa8e55aa3854325d2108b8df/LitePlacer/TinyG.cs#L394-L410

They are not actually Z probing but Z homing using G28.4. For this they are on-the-fly reconfiguring the switches of the Z axis, and then back. Which also means they are writing twice to the EEPROM on each probe. Very ugly.

The G28.4 command is undocumented, but see here:

"G28.4 homing cycle with no coordinate setting"
https://github.com/synthetos/TinyG/blob/39df38c0e5830721fb2d16a7ae7b44816d24c4c4/firmware/tinyg/canonical_machine.h#L381

I removed the SPINDLE_OFF in the "best for PnP" build.

See here (updated):

https://makr.zone/tinyg-new-g-code-commands-for-openpnp-use/577/

Note: I only updated the ADC enabled build. Make sure you have not used the SS2 signal for other purposes.

@Jim, please flash the new firmware and retry. Note: this time there is no need for the elaborate settings backup etc.

It would be great if you could test this! 😁

I've added a "documentary" PR too:

https://github.com/synthetos/TinyG/pull/276

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/81285967-43d2-480d-9230-660a9bced837n%40googlegroups.com.

[Jim Young]

Thank you Mark and others for all your help! I will test this out today, for sure.

>> For this they are on-the-fly reconfiguring the switches of the Z axis, and then back. Which also means they are writing twice to the EEPROM on each probe. Very ugly.

What!? Wouldn't that slowly destroy the EEPROM?

[mark maker]

> What!? Wouldn't that slowly destroy the EEPROM?

Yes. Like I said: Very ugly.

... in a DIY/spare time/hobby environment where you do a few boards per year, probably still not really going to matter...

But because TinyG is going brain-dead while writing to the EEPROM (not handling interrupts), they had to add a 50ms pause after each command:

https://github.com/jkuusama/LitePlacer-DEV/blob/0607c29c5cca4654fa8e55aa3854325d2108b8df/LitePlacer/TinyG.cs#L394-L410

Really. Very. Ugly. 🤮

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/b2f323c7-8d9f-4859-a417-b5aacccf6e5cn%40googlegroups.com.

[Jim Young]

I flashed my TinyG with this new firmware and now I'm getting the vacuum shutoff at the correct time when placing a part. I did have to reconfigure my probing offsets. I had overcompensated the values to deal with the vacuum being shut off too early in the prior firmware.

I did a comparison of my TinyG settings and I have noticed some odd differences:

$yjm is now set to 101 

Before flashing the firmware $yjm=2500

I'm noticing more noise from the stepper motor when moving in the Y directions. Could this be attributed to $yjm=101? I tried setting $yjm=2500, but every time I move the head it reverts back to 101. Is this normal?

[mark maker]

> I did a comparison of my TinyG settings and I have noticed some odd differences:
> $yjm is now set to 101
> Before flashing the firmware $yjm=2500

Are you sure? Because if I look back into your last settings posted in this thread (23.04.22, 16:41), I see $yjm=101.

> I'm noticing more noise from the stepper motor when moving in the Y directions. Could this be attributed to $yjm=101?

Similar to these noise differences? Then yes.

https://youtu.be/6SBDApObbz0?t=39

> I tried setting $yjm=2500, but every time I move the head it reverts back to 101. Is this normal?

The resetting is very strange. I have not even the beginning of a clue what this could be. 🙁

But in such cases, sometimes a true power-off for a minute helps. I know this does not sound "professional", but it surprisingly often helped me. No software/firmware is really bug-free, true power off is a clean slate.

Report back if it persists.

Also check your CONNECT_COMMAND for "stray" settings.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/cb360fbb-f9ca-44a7-a0eb-f1044dc5e31dn%40googlegroups.com.

[Jim Young]

Thanks, Mark, I'll be looking more into this problem.

Again, thank you, Mark and everyone else, for helping to solve this probing issue!

It's interesting that in the end it was a software problem.

[bert shivaan]

The folks here ROCK for sure!! Fixing stuff that is not even their stuff :)

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/8f146039-9dd1-4f64-8efd-ee872a546132n%40googlegroups.com.