Visual homing succeeds only the first time
486 views
Skip to first unread message
Tomislav Darlic
Jun 17, 2019, 3:30:19 PM6/17/19
to OpenPnP
Hi guys
I realized that if I reset the Smoothieboard before homing then homing is executed perfectly every time.
I've been trying to solve this issue with OpenPNP failing to visual home after first attempt. Visual homing succeeds the first time but on every consecutive homing attempt fails because the head overshoots the homing fiducial. My homing fiducial is X:10.5mm and Y:2.5mm away from the mechanical homing position. On second homing attempt the head will move 21mm in X and 5 mm in Y direction like it added the coordinates to the movement command and then search for fiducial. On third homing attempt it will move 31.5mm in X and 7.5 mm in Y and then search for fiducial and obviously fail to find it.
My visual homing is set up like this in the machine XML
<homing-fiducial-location units="Millimeters" x="10.5" y="2.5" z="0.0" rotation="0.0"/>I noticed that if I change above line in the machine.xml to have x="0" y="0" instead of x="10.5" y="2.5" and then reset the OpenPNP the OpenPNP resets the machine XML and reverts those values back to x="10.5" y="2.5".
This issue popped up after I upgraded to latest version of OpenPNP. Unfortunately I don't have the old installation file to revert back to previous version to test this but I was using my machine for 3 days before the upgrade without any problems.
Not knowing better I have created the below bug report in OpenPNP Github account before I discussed it here. I have removed the M82 command as per Marks recommendation on Github but the issue remains.
Does anyone have a clue what might be the problem here? I am out of ideas after googling and trying for several days now.
Thanks
Jason von Nieda
Jun 17, 2019, 3:48:56 PM6/17/19
to ope...@googlegroups.com
Hi Tomislav,
Thanks for posting the diagnostics. I'll take a look at this issue tonight or tomorrow night and see if I can help.
In the meantime, one thing you mentioned stuck out to me: If you are hand editing the machine.xml, make sure you do it when OpenPnP is not running. If it's running when you make the change the change will be reverted on shutdown.
If OpenPnP is NOT running when you made this change, and it is still resetting it to the old value, that is very strange. Just to be sure, are you editing the machine.xml in .openpnp2, not .openpnp?
Thanks,
Jason
--
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 post to this group, send email to ope...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/6d80c201-df94-4969-b1ee-3389ecf4248f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Tomislav Darlic
Jun 17, 2019, 3:59:42 PM6/17/19
to OpenPnP
Thanks Jason for fast reply
I don't see the .openpnp2 in my user directory. Is it supposed to be there?
I have retested this resetting to old values in the machine.xml and it was my mistake. The programs window closes but it still remains in the memory a short period. It appears that I have changed the values after closing but too fast to allow the program to close fully. I have machine.xml opened in Notepad++ at all times and it pops up a warning when files changes.
TDarlic
On Monday, June 17, 2019 at 9:48:56 PM UTC+2, Jason von Nieda wrote:
Hi Tomislav,Thanks for posting the diagnostics. I'll take a look at this issue tonight or tomorrow night and see if I can help.In the meantime, one thing you mentioned stuck out to me: If you are hand editing the machine.xml, make sure you do it when OpenPnP is not running. If it's running when you make the change the change will be reverted on shutdown.If OpenPnP is NOT running when you made this change, and it is still resetting it to the old value, that is very strange. Just to be sure, are you editing the machine.xml in .openpnp2, not .openpnp?Thanks,Jason
On Mon, Jun 17, 2019 at 2:30 PM Tomislav Darlic <tomisla...@gmail.com> wrote:
Hi guys--I've been trying to solve this issue with OpenPNP failing to visual home after first attempt. Visual homing succeeds the first time but on every consecutive homing attempt fails because the head overshoots the homing fiducial. My homing fiducial is X:10.5mm and Y:2.5mm away from the mechanical homing position. On second homing attempt the head will move 21mm in X and 5 mm in Y direction like it added the coordinates to the movement command and then search for fiducial. On third homing attempt it will move 31.5mm in X and 7.5 mm in Y and then search for fiducial and obviously fail to find it.My visual homing is set up like this in the machine XML
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 ope...@googlegroups.com.
Tomislav Darlic
Jun 19, 2019, 4:01:14 AM6/19/19
to OpenPnP
Hi guys
I've been struggling with this issue for days now. The way I home my machine now is to close OpenPnP and then reset the Smoothieboard and then home. This works every time but is annoying. I tried to flash new firmware to the Shmoothieboard but this didn't help. I've changed the SD card hoping this might somehow be cause.
I am pretty sure that every time the machine homes the coordinates of the homing fiducial somehow gets added to the "home" position and the head overshoots the visual homing position. If I repeat the homing 10 times the head moves 105 mm away in X.
I was trying to figure out what command to issue in in my limited knowledge of G Code so that the homing position is reset but any combination I tried resulted in same result.
Can I download the older version of OpenPnP somewhere and try it?
TDarlic
Jason von Nieda
Jun 19, 2019, 10:38:51 AM6/19/19
to ope...@googlegroups.com
Hi Tomislav,
I see the error in the logs. The problem is that the G92 sent after visual homing is sending 0,0 when it should send the position of the home fiducial. I think this is a bug, but I'm not sure how it happened, since I don't think that code has changed in quite a while. I will look at this closer this evening and see if I can find out what is happening.
In the meantime, I think you can fix this by adding a home-coordinate to your X and Y axes in GcodeDriver config. See the home-coordinate field in https://github.com/openpnp/openpnp/wiki/GcodeDriver%3A-Axis-Mapping#defining-axes. You should set the home-coordinate for X and Y to the same values you have set for your homing-fiducial-location: <homing-fiducial-location units="Millimeters" x="10.5" y="2.5" z="0.0" rotation="0.0"/>
I think that will fix the issue for now, and I'll investigate into why it's happening.
Thanks,
Jason
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/a1cd76cb-698a-4c39-bb63-845db10e879a%40googlegroups.com.
Mark
Jun 19, 2019, 1:16:39 PM6/19/19
to ope...@googlegroups.com
> The problem is that the G92 sent after visual homing is sending 0,0 when it should send the position of the home fiducial.
Yes that was my first thought too (because I stumbled on that on my “home-to-max Y” machine). OpenPNP internally resets the same home coordinates twice.
After end-switch homing:
After visual homing:
I assumed OpenPNP wants the fiducial to be your new home with the same home coordinates. I don’t know if this is a bug or wanted behavior. I just added a G0 command to my HOME_COMMAND to move the machine to the fiducial, before the first internal OpenPNP coordinate resetting happens.
But even if it is a bug: how does it explain the behavior?
The fiducial is close enough so it works in the first homing. Both Smoothie and OpenPNP are reset (see first code ref above) to the same respective coordinates after the G28 end-switch homing both times.
So why would the second visual homing behave any different? And why would that result in incrementally longer and longer offsets?
I suspect there’s something wrong with absolute mode or Smoothie G28.
Have you engaged grbl mode? This could explain it!
http://smoothieware.org/supported-g-codes
Either switch off grbl mode or use $H to home instead of G28.
_Mark
Marek T.
Jun 19, 2019, 2:08:12 PM6/19/19
to OpenPnP
"POST_VISION_HOME_COMMAND" contains the homing coordinates as are needed to be set after the visual homing, isn't it?
Jason von Nieda
Jun 19, 2019, 11:58:16 PM6/19/19
to ope...@googlegroups.com
Mark - I think you are right. Let's see what Tomislav says.
Jason
--
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 post to this group, send email to ope...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/006001d526c2%24c1340360%24439c0a20%24%40makr.zone.
Tomislav Darlic
Jun 24, 2019, 3:44:18 AM6/24/19
to OpenPnP
Thanks guys for the update. Unfortunately I am on a business trip until Wednesday and will test the above as soon as I return.
On Thursday, June 20, 2019 at 5:58:16 AM UTC+2, Jason von Nieda wrote:
Mark - I think you are right. Let's see what Tomislav says.Jason
On Wed, Jun 19, 2019 at 12:16 PM Mark <mark(at)makr.zone> wrote:
--> The problem is that the G92 sent after visual homing is sending 0,0 when it should send the position of the home fiducial.
Yes that was my first thought too (because I stumbled on that on my “home-to-max Y” machine). OpenPNP internally resets the same home coordinates twice.
After end-switch homing:
After visual homing:
I assumed OpenPNP wants the fiducial to be your new home with the same home coordinates. I don’t know if this is a bug or wanted behavior. I just added a G0 command to my HOME_COMMAND to move the machine to the fiducial, before the first internal OpenPNP coordinate resetting happens.
But even if it is a bug: how does it explain the behavior?
The fiducial is close enough so it works in the first homing. Both Smoothie and OpenPNP are reset (see first code ref above) to the same respective coordinates after the G28 end-switch homing both times.
So why would the second visual homing behave any different? And why would that result in incrementally longer and longer offsets?
I suspect there’s something wrong with absolute mode or Smoothie G28.
Have you engaged grbl mode? This could explain it!
http://smoothieware.org/supported-g-codes
Either switch off grbl mode or use $H to home instead of G28.
_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 ope...@googlegroups.com.
Tomislav Darlic
Jul 29, 2019, 4:31:15 PM7/29/19
to OpenPnP
HI guys
Sorry it took this long to get back to my machine and test this.
I've tried to input home-coordinate values as per machine.xml excerpt below and the behavior is still the same. Every time it homes it overshoots more and more.
<axes class="java.util.ArrayList">
<axis name="x" type="X" home-coordinate="10.5">
<head-mountable-ids class="java.util.HashSet">
<string>*</string>
</head-mountable-ids>
</axis>
<axis name="y" type="Y" home-coordinate="2.5">
<head-mountable-ids class="java.util.HashSet">
<string>*</string>
</head-mountable-ids>
</axis>
But then I explicitly disabled the grbl mode in smoothieboard config.txt as Marek T. suggested and restarted the board and it seems to be working fine now. It homes to homing fiducial every time. I did not have the time to test it in production but I've tried several board and visual placements and it seems to be working OK.
The smoothieboard was never placed in grbl mode by myself and the command was not present in the config.txt. It started to work properly only after I set it to false in config.txt. I am starting to suspect my smoothieboard is somehow faulty.
TDarlic
You received this message because you are subscribed to a topic in the Google Groups "OpenPnP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/aaVr5LwxM6Q/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openpnp+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/1c817128-4cb7-4a65-9e60-77c9c3cb178b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages