How to set Z home?
jbasia
mark maker
> 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.
mark maker
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.
jbasia
is merely a human or esthetic one.
mark maker
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.
jbasia
jbasia
jbasia
jbasia
mark maker
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.
jbasia
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 am using LinuxCNC (= Debian 10 I believe).
s etc. I guess Linux really, really sucks there.
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?
Like have the controller connected directly and the cameras through a hub. Does active/passive might make a difference? (I mean if it works in the first place)
I would really prefer that.
> 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:
I have 3, an air pump and 2 vac pumps. All I can switch, but only the vac pumps are operational. So I just did a test with small piece of paper - when I switch valve off the paper falls off instantly. I see no difference with or without the pressure pump. I tend to go ahead without the pressure pump for now. Once I start assembly I will observe it.
> 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.
After fixing this, press Find Issues & Solutions again and accept the proposed HOME_COMMAND. Then test again.
Find Issues & Solutions brings up the Set Safe Z of N1, N2 again. I can set N2, but N1 can't get low enough (was fine before). Home for Z (never in balance) is every time different.
Please let me know your comment on hubs.
jbasia
{False:M42 PIndex S0}
mark maker
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.
jbasia
mark maker
> 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:
- First, you need to understand the difference between functional
axes and motor axes:
- Functional axes Z1 and Z2 are the Z axes along which the
nozzles move.
- The Motor axis Z is shared between them, and in your case rotates
the cam, so Z1 and Z2 move relative to the sine
of the motor coordinate (one negated).
- Then you should understand that Soft Limits and Save Z limits are properties of the motor axis, not the functional axis.
- Then you should distinguish between Soft Limits and Save Z limits:
- The Soft Limits are the very extremes of how far the
motor axis is allowed to move, as controlled by OpenPnP.
- For shared Z motor axis, the Safe Z Zone is a range in
the middle, where both axes are lifted up sufficiently to clear
any obstacle on the machine.
- There are two methods to control Safe Z, the efficient Dynamic
Safe Z that takes the part height into consideration and
lazily only lifts the nozzle as much as needed, and the less
efficient Fixed Safe Z methods that always lifts the
nozzle up with the highest-ever part in mind, or even to the
balance point, where the two nozzles are at equal heights (if
you have a craving for tidily balanced nozzles).
- Follow Issues & Solutions and read the Wiki link below for more info, it hopefully lays all that out.
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.
jbasia
- s (if you have a craving for tidily balanced nozzles).
2023-01-30 14:52:00.255 AbstractHeadMountable DEBUG: N2.moveTo((0.000000, 100.000000, 15.750000, 0.000000 mm), 1.0)
2023-01-30 14:52:00.263 GcodeDriver DEBUG: [serial://COM3] >> M204 S667, 20000
2023-01-30 14:52:00.264 GcodeDriver$ReaderThread TRACE: [serial://COM3] << ok
2023-01-30 14:52:00.265 GcodeDriver TRACE: [serial://COM3] confirmed M204 S667
2023-01-30 14:52:00.265 GcodeDriver DEBUG: [serial://COM3] >> G1 Z-70.1017 F6911 ; move to target, 20000
2023-01-30 14:52:00.266 GcodeDriver$ReaderThread TRACE: [serial://COM3] << ok
2023-01-30 14:52:00.266 GcodeDriver TRACE: [serial://COM3] confirmed G1 Z-70.1017 F6911 ; move to target
2023-01-30 14:52:00.269 AbstractMachine TRACE: Machine entering idle state.
2023-01-30 14:56:25.749 ReferenceMachine DEBUG: homing machine
2023-01-30 14:56:25.751 GcodeDriver DEBUG: [serial://COM3] >> M204 S666.67 ; Initialize acceleration, -1
2023-01-30 14:56:25.752 GcodeDriver$ReaderThread TRACE: [serial://COM3] << ok
2023-01-30 14:56:25.753 GcodeDriver TRACE: [serial://COM3] confirmed M204 S666.67 ; Initialize acceleration
2023-01-30 14:56:25.753 GcodeDriver DEBUG: [serial://COM3] >> G28 ; Home all axes, -1
2023-01-30 14:56:27.753 GcodeDriver$ReaderThread TRACE: [serial://COM3] << echo:busy: processing
2023-01-30 14:56:29.753 GcodeDriver$ReaderThread TRACE: [serial://COM3] << echo:busy: processing
2023-01-30 14:56:31.031 GcodeDriver$ReaderThread TRACE: [serial://COM3] << X:0.00 Y:0.00 Z:0.00 A:50.00 B:50.00 C:50.00 Count X:0 Y:0 Z:0 A:2500 B:2500 C:500
2023-01-30 14:56:31.031 GcodeDriver TRACE: Position report: X:0.00 Y:0.00 Z:0.00 A:50.00 B:50.00 C:50.00 Count X:0 Y:0 Z:0 A:2500 B:2500 C:500
2023-01-30 14:56:31.032 GcodeDriver WARNING: Position report cannot be processed when motion might still be pending. Missing Machine Coordination on Actuators?
2023-01-30 14:56:31.032 GcodeDriver$ReaderThread TRACE: [serial://COM3] << ok
2023-01-30 14:56:31.032 GcodeDriver TRACE: [serial://COM3] confirmed G28 ; Home all axes
2023-01-30 14:56:31.032 GcodeDriver DEBUG: [serial://COM3] >> M400 ; Wait for moves to complete before returning, -1
2023-01-30 14:56:31.033 GcodeDriver$ReaderThread TRACE: [serial://COM3] << ok
2023-01-30 14:56:31.033 GcodeDriver TRACE: [serial://COM3] confirmed M400 ; Wait for moves to complete before returning
2023-01-30 14:56:31.033 AbstractMotionPlanner DEBUG: Reported location changes current location from (x:0.000000, y:100.000000, ZN:-70.101746, C1:0.000000, C2:0.000000) to (x:0.000000, y:0.000000, ZN:0.000000, C1:0.000000, C2:0.000000)
2023-01-30 14:56:31.034 ReferenceHead DEBUG: H1.home()
2023-01-30 14:56:31.034 ReferenceNozzle DEBUG: N1.home()
2023-01-30 14:56:31.034 ReferenceNozzle DEBUG: N2.home()
2023-01-30 14:56:31.035 Scripting TRACE: Scripting.on Machine.AfterHoming
2023-01-30 14:56:31.035 ReferenceMachine INFO: setHomed(true)
2023-01-30 14:56:31.036 AbstractMachine TRACE: Machine entering idle state.
jbasia
2023-01-30 15:08:55.053 GcodeDriver DEBUG: [serial://COM3] >> M204 S667, 20000
2023-01-30 15:08:55.054 GcodeDriver$ReaderThread TRACE: [serial://COM3] << ok
2023-01-30 15:08:55.055 GcodeDriver TRACE: [serial://COM3] confirmed M204 S667
2023-01-30 15:08:55.055 GcodeDriver DEBUG: [serial://COM3] >> G1 Z-10.3176 F2882 ; move to target, 20000
2023-01-30 15:08:55.056 GcodeDriver$ReaderThread TRACE: [serial://COM3] << ok
2023-01-30 15:08:55.056 GcodeDriver TRACE: [serial://COM3] confirmed G1 Z-10.3176 F2882 ; move to target
2023-01-30 15:08:55.060 AbstractMachine TRACE: Machine entering idle state.
2023-01-30 15:08:55.060 ReferenceActuator DEBUG: LIGHT_BOTTOM.actuate(true)
2023-01-30 15:08:55.060 GcodeDriver DEBUG: [serial://COM3] >> M42 P23 S255, 20000
2023-01-30 15:08:55.062 GcodeDriver$ReaderThread TRACE: [serial://COM3] << ok
2023-01-30 15:08:55.062 GcodeDriver TRACE: [serial://COM3] confirmed M42 P23 S255
mark maker
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.
mark maker
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.
jbasia
mark maker
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.
mark maker
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.
jbasia
mark maker
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.
jbasia
jbasia
mark maker
> 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.
mark maker
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"/>
https://groups.google.com/g/openpnp/c/b9vLFlRp0Rs/m/d9O4_ssOBgAJ
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.
jbasia
mark maker
> I am not clear what I should put in there.
- You should probably revisit the Soft Limits: go to the
ZN axis and disable the Soft Limit Low / Soft
Limit High, Enabled? switches.
- Then press Find Issues & Solutions on the Issues & Solutions tab.
- The solutions "Set the low side soft limit of ZN" and "Set the
high side soft limit of ZN" should appear. Do not handle
them yet.
- Then you should re-visit the Safe Z solutions by enabling Include Solved? on the Issues & Solutions tab.
- Look for "Dynamic Safe Z for N1" / "Dynamic Safe Z for N2" and
"Set Safe Z of N1" / "Set Safe Z of N2". They should appear above
the Soft-Limit solutions.
- Press Reopen on these four.
- Then press Find Issues & Solutions, again.
- Then do them in order, this time very carefully reading the instructions and perhaps pressing the lower blue info button.
- After the "Dynamic Safe Z" solutions have been done, press Find
Issues & Solutions to see the "Set Safe Z" solutions,
i.e., the must come after.
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.
jbasia
M18 Z ; power off Z motor
jbasia
G4 P500 ; wait for the spring to roughly home it
M17 Z ; power on Z Motor
{Acceleration:M204 S%.2f ; Initialize acceleration}
G28 X0 Y0; Home all axes
mark maker
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.
jbasia
#define Z_MIN_POS -10
#define Z_MAX_POS 10
#define Z_HOME_DIR 0
#define Z_MAX_POS 10
jbasia
2023-02-09 16:56:03.437 AbstractHeadMountable DEBUG: N1.moveToSafeZ(1.0)
2023-02-09 16:56:03.438 AbstractHeadMountable DEBUG: N2.moveToSafeZ(1.0)
2023-02-09 16:56:03.438 AbstractHeadMountable DEBUG: Top.moveToSafeZ(1.0)
With the new HOME at the front left the Head goes X0 first and then moves over all the tapes, clearance is maybe only 5mm or so. Would be safer to go Y0 first but I presume that is somewhere hard coded and can't be changed..
mark
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.
jbasia
Even though Z has no end switches. I got firmware writing error before when I commented it out. But right now tried again commenting it out an it wrote the firmware. Not tested yet. This said, in normal operation I never hit the ends. Even when Z acts "funny" it rarely goes to that extreme.
mark maker
> 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.
jbasia
mark maker
> 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.