> I have some issues with Z-Home for the 2 nozzles. In home position they should be equal heights. Which they are when I start the machine. But after P they are lightly out of balance.
If you follow Issues & Solutions closely, these
things are explained and you can choose between an "old-style" Fixed
Safe Z handling of Z axes, that is always balanced and
simple, but less efficient (slower), and a modern Dynamic
Safe Z handling of Z axes, where the motion is
optimized (faster), but nozzles may appear lopsided.
https://github.com/openpnp/openpnp/wiki/Kinematic-Solutions#dynamic-safe-z
The controller and OpenPnP always know where the Z axes are, so
the "confusion" is merely a human or esthetic one.
In the Dynamic Safe Z mode, the Z axis P button does not balance the nozzles, but lift them to the minimum Z that is considered safe. So if you select the left/right nozzle, you typically get two different (lopsided) positions.
> Additionally, where I increase the speed? A `10` takes like 3 Seconds.
Please ask this in a separate discussion thread with its own
fitting subject title.
_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/7405ce99-5dc6-4523-8ca3-ffef7a003d5en%40googlegroups.com.
What I wanted (but forgot) to mention is that you should press the blue info button (the lower one) to jump to the Wiki that explains these solutions:
> I have some issues with Z-Home for the 2 nozzles. In home position they should be equal heights. Which they are when I start the machine. But after P they are lightly out of balance.
If you follow Issues & Solutions closely, these things are explained and you can choose between an "old-style" Fixed Safe Z handling of Z axes, that is always balanced and simple, but less efficient (slower), and a modern Dynamic Safe Z handling of Z axes, where the motion is optimized (faster), but nozzles may appear lopsided.
https://github.com/openpnp/openpnp/wiki/Kinematic-Solutions#dynamic-safe-z
The controller and OpenPnP always know where the Z axes are, so the "confusion" is merely a human or esthetic one.
In the Dynamic Safe Z mode, the Z axis P button does not balance the nozzles, but lift them to the minimum Z that is considered safe. So if you select the left/right nozzle, you typically get two different (lopsided) positions.
> Additionally, where I increase the speed? A `10` takes like 3 Seconds.
Please ask this in a separate discussion thread with its own fitting subject title.
_Mark
On 1/27/23 08:44, jbasia wrote:
I have some issues with Z-Home for the 2 nozzles. In home position they should be equal heights. Which they are when I start the machine. But after P they are lightly out of balance.--
It uses the "Cam" system with the balance.
This is how it is about now (from my Windows PC, actual machine uses LinuxCNC/Debian). I have a `M92 Z10` setting, so a `1` in jog mode gives me about 1mm up/down.
Additionally, where I increase the speed? A `10` takes like 3 Seconds.
--
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/7405ce99-5dc6-4523-8ca3-ffef7a003d5en%40googlegroups.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 openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/f3db2be8-bd64-d2c5-ce8e-fe1be23bc94a%40makr.zone.
is merely a human or esthetic one.
Actually I liked the start of the video, when it embraces Issues
& Solutions, but then it strays from that path, and recommends
a bunch of stuff that I have to say is ... erm ...
"counter-productive" to say it nicely.
I commented under the video:
@quertymodo, you started out nicely, then unfortunately strayed from the Issues & Solutions path. Many things you do manually can be done automatically, and with proper guidance, many hard-learned sanity checks and most importantly in the right order when using Issues & Solutions.
Please, everybody, do not delete your virtual axes, just learn how to use them properly and benefit.
If there really are Lumen specific issues with the auto-generated actuators, please report to the discussion group, so this can be improved, though I have not seen anything in the video. Of course the G-code needs to be specific, but this can just equally be entered for the auto-generated actuators, any nicely guided by Issues & Solutions. By deleting actuators, you are causing much unnecessary work (and invite human error).
Soft limits should be set by jogging the machine to the actual limits, as I&S suggests, so you would not have had the crash in backlash calibration later, and no restoring of (apparently faulty) soft-limits necessary later. Similar for Safe Z.
There is also a misunderstanding in the axis units per millimeter discussion. OpenPnP does not set these on the controller, it only needs to know them. So you should enter the 39.88 you measured there, in addition to configuring the controller using M92.
Please use Issues & Solution to calibrate the camera units per pixel etc., don't do this manually (in fact you do that next in the video, so that was completely unnecessary).
Neither the virtual Z axis, nor the secondary fiducial calibration have anything to do with "auto focus cameras only", but with camera focal length i.e. objects appear larger when nearer in Z, and OpenPnP needs to know how much. So the secondary fiducial calibration needs to be done at a different Z.
Do not skip the nozzle offsets steps. Your guide of matching up cameras and nozzles in cross-hairs is prone to camera tilt errors, certainly much less precise, and strangely more work than the automated I&S way. I doubt you can pick and place accurately based on that.
Also do not calibrate the nozzle tips using an outer feature up the tip, it needs to be at the lower-most Z of the nozzle tip, ideally the bore. I&S will again guide you. And zoom in the camera (scroll wheel).
Please, everybody, proceed as recommended by I&S and use the blue info buttons to jump to the Wiki for more information, about the needed calibration rig.
The version of OpenPnP recorded here is already strongly outdated, the current test version covers many more setup issues, including actuators, camera device settings, nozzle tip calibration etc. all with Issues & Solutions guidance and Wiki links.
Finally, the screen recorder did not record the pipeline editor in the nozzle tip calibration sequence (near end of video), which is actually good, because users should not need to edit the pipeline at all.
If you followed the video regarding Safe Z (i.e. not Issues & Solutions) and his manual way of setting nozzle offsets, that explains why you were not confronted with the proper Safe Z suggestions by I&S.
We are investing tons of hours into improving the "wisdom" going into Issues & Solutions. Please use it. And if anybody has reason to believe that I&S leads you astray, please report it here. We are constantly improving it.
These videos are also outdated (many things since improved), by
they still explain some of the underlying reasoning, like the
secondary fiducial and "3D calibration":
https://www.youtube.com/watch?v=md68n_J7uto
https://www.youtube.com/watch?v=Pxg6g3KI5_E
_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/ba8f90b2-79f3-4534-a1b0-bc3bfbde27f9n%40googlegroups.com.
The following assumes you have the newest OpenPnP testing
version.
> Cameras sort of work up to 352 x 288 MJPG. 640 x 480
should work, but sometimes OpenPNP freezes and needs a kill.
Is that under Linux? I myself have a terrible experience under Linux (Kubuntu 22.04), but that is not restricted to OpenPnP! Any other WebCam tool I tried has the same issues. Hangs, black views, internal notebook webcam only working intermittently, lost camera settings etc. I guess Linux really, really sucks there.
But from a fresh desktop login I managed to setup the camera all
right then save the configuration.
I also added the Freeze Camera Settings option to remedy "lost settings".
https://github.com/openpnp/openpnp/wiki/OpenPnpCaptureCamera#freezing-camera-properties
From then on I was able to use the cameras, as long as I did not
go fiddle with the settings. If you use Linux as well, please
report your findings.
> Actuators work with `M42 P{Index} S{True:255}{False:0}` ... So all green.
Have you tried using the Issues & Solutions way? You can just enter ON and OFF commands separately, and I&S will automatically do the proper encoding with {True:} {False:} for you:
ON-Switching:
M42 P{Index} S255
OFF Switching
M42 P{Index} S0
Isn't that easier? 😁
https://github.com/openpnp/openpnp/wiki/Setup-and-Calibration_Actuators#assigning-commands
> (I need to add some some pump logic later).
Be sure to read about the new Pump Control:
https://github.com/openpnp/openpnp/wiki/Setup-and-Calibration_Vacuum-Setup#pump-control-setup
> Can jog. But HOME had no function. But G28 in the console works. There is also a G28 in the Gcode driver Home setting. Got a timeout error and I had to remove: `{Acceleration:M204 S%.2f} ; Initialize acceleration` ... Homing also has a sound issue with Y
This points to a misconfiguration of your Y axis acceleration limit.
Please report your findings, or send the machine.xml.
After fixing this, press Find Issues & Solutions
again and accept the proposed HOME_COMMAND.
Then test again.
_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/1cb85d9b-9857-4bb1-a373-1d001c01ab92n%40googlegroups.com.
The following assumes you have the newest OpenPnP testing
version.
> Cameras sort of work up to 352 x 288 MJPG. 640 x 480
should work, but sometimes OpenPNP freezes and needs a kill.
Is that under Linux?
s etc. I guess Linux really, really sucks there.
> Actuators work with `M42 P{Index} S{True:255}{False:0}`
... So all green.
Have you tried using the Issues & Solutions way?
Be sure to read about the new Pump Control:
> Can jog. But HOME had no function. But G28 in the
console works. There is also a G28 in the Gcode driver Home
setting. Got a timeout error and I had to remove:
`{Acceleration:M204 S%.2f} ; Initialize acceleration` ... Homing
also has a sound issue with Y
This points to a misconfiguration of your Y axis acceleration limit.
Please report your findings, or send the machine.xml.
After fixing this, press Find Issues & Solutions again and accept the proposed HOME_COMMAND. Then test again.
Hi jbaisa
> BTW, the solution method for actuators did not work
Thanks for reporting back.
This should now be solved in the new testing version.
> Also after setting N, N2 will goes to lowest
position when homing, can hit something high on the machine. So
Z homing after setting in Windows still not working.
I don't really understand. Perhaps send the machine.xml.
> Problem is the other PC in the room is a bit far. I have a
modern notebook that is sort of free to use - but has only 2 USB
slots. What is your comment on hubs?
If you have high quality cameras (e.g. FullHD ELP) they need a
dedicated USB root hub i.e. a different USB port on the
computer. The can still go through an external hub and share it
with the controller or other low-bandwidth USB devices, just
not with the other camera (too much sum bandwidth).
_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/8a6b6dce-d443-42e0-88b8-b5c2e5a80ba5n%40googlegroups.com.
> In the setup I am ask to set N1/2 low, clear, but also
N1/2 high - it does not make sense to me.
I still don't understand what you mean in relation to OpenPnP
terms, so I just lay out some of these. The following is numbered
for easy references, and I assume you already know most of it, so
it is not meant to be condescending, just hopefully useful for a
wider audience:
I have just now slightly update the Wiki to make these points
clearer, especially here:
https://github.com/openpnp/openpnp/wiki/Kinematic-Solutions#capture-soft-limits
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/11cd68bf-6d57-4973-afe6-42f89df84001n%40googlegroups.com.
It looks as if you are below the range where the the cam can still move. It is blocked by the N1 stepper body (yellow arrow).
You must set the Z Soft Limits so that the cam and rollers are
still in their articulation ranges.
_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/613ccc81-c276-4d8d-a659-f14caa0dd2f7n%40googlegroups.com.
I used your image for a better explanation it in the Wiki:
https://github.com/openpnp/openpnp/wiki/Kinematic-Solutions#special-considerations-for-z-axes
Hope you're OK with that, otherwise tell me.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/b2bbb394-10f1-76a4-ceba-789c7b7cb0b9%40makr.zone.
It just occurred to me that there could be another problem.
Question: how does the machine home the Z axis. At the balance point? Does it set Z to 0 there?
For the potential problem, see here:
https://github.com/openpnp/openpnp/wiki/Machine-Axes#a-word-about-z-coordinates
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/2e9234fc-bd96-3f81-690f-9ea19248e351%40makr.zone.
That points to the same problem I suspect in the other mail that
I just sent.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/d7e6041a-e96e-4267-b4fd-9a862d05c689n%40googlegroups.com.
Does the head have a mid-way homing switch?
I mean is homing Z at all working outside OpenPnP?
> Can't I simply keep/set the Z:0.000 state when I switch
the machine ON as Home?
If they are not blocked when balanced, then "perhaps". It would
likely not be very accurate/repeatable, as it is dependent on the
balance of the spring forces.
You would have to configure marlin as much, i.e. not set the Z
axis up for homing.
Alternatively (not as good a solution), you could configure the
HOME_COMMAND, only adding the axes to G28 you want to home:
G28 X0 Y0
(assuming Marlin supports this form like other firmwares do).
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/969fc1a4-77b5-4731-bb8f-dce67f7a4d39n%40googlegroups.com.
> Well, mostly. Sometimes the machine seems to forget where
Z0 is and is out of balance. I need to switch power off and
restart then.
This should only happen, if you stall the Z motor.
If that is not the cause, then please find the real cause, otherwise we both will waste our time chasing our tails here.
>Another issue is that sometimes one nozzle will go max down when travelling. Again an obstacle hit risk!
Something is wrong. Like I said you need to eliminate the
underlying cause. Send log and machine.xml
> I need to switch power off and restart then.
On most controllers, you can also power off motors using Gcode. On Marlin it seems to work like this:
https://marlinfw.org/docs/gcode/M018.html
https://marlinfw.org/docs/gcode/M017.html
So you could add a Z power off command to HOME_COMMAND
to let the spring do its work.
I suggest a two phase approach with a repeatable spring retraction on the second spring relaxation to improve homing accuracy:
M18 Z ; power off Z motor G4 P500 ; wait for the spring to roughly home it M17 Z ; power on Z Motor G4 P200 ; wait for motor to hold G1 Z-5 ; pull Z to one side for repeatable spring retraction M18 Z ; power off Z motor again G4 P1000 ; wait for the spring to accurately home it, no vibrations M17 Z ; power on Z Motor G4 P200 ; wait for motor to hold G92 Z0 ; set Z to 0 {Acceleration:M204 S%.2f ; Initialize acceleration} G28 ; Home all axes
Obviously the G4 dwell times have to be tuned to allow for the machine to settle into the states (no vibrations left).
The retract distance for the repeatable spring relaxation (-5 in
the example) would have to be tuned too. For it to be effective,
the repeatable spring relaxation must pull the nozzle slightly
away from being blocked, maybe 1mm, so it always snaps back from
the same side and same distance when the motor is unpowered.
Note, if the head design has a dead zone, i.e., if both
steppers are blocked when balanced, and the cam has a certain wiggle
room, then the ideal G92 Z
coordinate would not necessarily be 0.
The cam must be positioned in the middle of the wiggle room when
at Z=0. To achieve that, run the above homing cycle with G92 Z0, then carefully jog the Z until
the cam is balanced in the middle of the wiggle room, then look at
the Z coordinate using M114 in the
console, then set the G92 Z
coordinate to the negative of that.
Report back if that is the case, and a video would be cool. 😁
This documentation all helps other (future) users too.
--
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/0c9968e5-6830-4e2e-b275-2109158c1a73n%40googlegroups.com.
It seems my earlier explanation that one must distinguish between Z Soft Limits and Safe Z Zone has not fallen on fertile ground.
They are practically the same in your machine.xml
<soft-limit-low value="-4.301222304670363" units="Millimeters"/> <soft-limit-high value="4.5" units="Millimeters"/> <safe-zone-low value="-4.061852520081943" units="Millimeters"/> <safe-zone-high value="4.468825667917284" units="Millimeters"/>
I spent a lot of time writing it. 🤨
And the Wiki:
https://github.com/openpnp/openpnp/wiki/Kinematic-Solutions#special-considerations-for-z-axes
And above all: read what I&S really tells you to do,
use the blue info buttons. If that stuff is not understandable,
report back.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/c394445a-08dd-4f9a-baba-645fe3ca0f75n%40googlegroups.com.
> I am not clear what I should put in there.
Wiki instructions starting from this:
https://github.com/openpnp/openpnp/wiki/Kinematic-Solutions#dynamic-safe-z
If still unclear, please report what exactly is the
difficulty.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/63a1663b-8422-4c79-aac9-67cab7d5a0d4n%40googlegroups.com.
M18 Z ; power off Z motor
You should use the two phase method I suggested earlier. There
are reasons I proposed this, especially if you have a dead
zone.
I suggest a two phase approach with a repeatable spring retraction on the second spring relaxation to improve homing accuracy:
M18 Z ; power off Z motor G4 P500 ; wait for the spring to roughly home it M17 Z ; power on Z Motor G4 P200 ; wait for motor to hold G1 Z-5 ; pull Z to one side for repeatable spring retraction M18 Z ; power off Z motor again G4 P800 ; wait for the spring to accurately home it, no vibrations M17 Z ; power on Z Motor G4 P200 ; wait for motor to hold G92 Z0 ; set Z to 0
{Acceleration:M204 S%.2f ; Initialize acceleration} G28 ; Home all axes
Obviously the G4 dwell times have to be tuned to allow for the machine to settle into the states (no vibrations left).
The retract distance for the repeatable spring relaxation (-5 in the example) would have to be tuned too. For it to be effective, the repeatable spring relaxation must pull the nozzle slightly away from being blocked, maybe 1mm, so it always snaps back from the same side and same distance when the motor is unpowered.
Note, if the head design has a dead zone, i.e., if both steppers are blocked when balanced, and the cam has a certain wiggle room, then the ideal G92 Z coordinate would not necessarily be 0. The cam must be positioned in the middle of the wiggle room when at Z=0. To achieve that, run the above homing cycle with G92 Z0, then carefully jog the Z until the cam is balanced in the middle of the wiggle room, then look at the Z coordinate using M114 in the console, then set the G92 Z coordinate to the negative of that.
Report back if that is the case, and a video would be cool. 😁 This documentation all helps other (future) users too.
--
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/f5bf571f-87a3-43a1-829b-1f3630db28fcn%40googlegroups.com.
On 9 Feb 2023, at 10:20, jbasia <china...@gmail.com> wrote:
Whatever I try - Z does not level at or near Z0. Without power Z levels perfectly - but the catches some value from somewhere. It renders "safe Z" meaningless.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/efe752c1-e856-447b-ab82-0d9fdf85cb05n%40googlegroups.com.
> The cam arm is so to speak touching both nozzles in the Zero position. Means any movement will effect ONE nozzle. And one only. No air in between.
When you say "and one only", does that mean that the nozzle blocking is perfectly aligned with the balance point?
If that is the case, then I see no reason why the unpowered
stepper followed by G92 Z0 should not home it perfectly.
I guess the problems are wholly in the Marlin config. Guess you
need to read yourself into that stuff better, or call out for help
on the Marlin forums.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/aafc4848-1a00-4c6d-a39c-9d4f7546867fn%40googlegroups.com.
> At power OFF they are perfectly aligned. There is zero space between cam arm and either nozzle. For both nozzles this is at the same time the highest point. One going down does not bring the other up. Doesn't that mean ZN safe zone high/low 0.00 should work?
Yes and if it does not, I guess something is wrong elsewhere.
> Also, shouldn't for ZN the green and blue Z coordinated to be the same?
No! Blue DRO coordinates are relative to the position at the time when you switched from green to blue.
> From my observation OpenPnP does something to ZN.
Not surprising when you misinterpret the DRO.
> Ideally ZN would be always in the center /0 position with
any XY move
> For my Nozzle type, what is better - Dynamic Z or Safe Z? I
In that case Fixed Safe Z is better. Then jog the Z to 0 to set
the Safe Z for both nozzles. The Safe Z Zone will be empty, the
nozzles always balanced.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/63d782ec-e505-418e-9b43-8320445eb386n%40googlegroups.com.