Homing to Fiducial in X and Y (offset )

103 views
Skip to first unread message

Mike Menci

unread,
Nov 15, 2021, 11:44:17 AM11/15/21
to OpenPnP
Hello Mark 
Could you please explain why my fiducial Homing is not working:
Explanation: 
1) If I test "visual test"  at HEADS / Ref Head H1 Homing X & Y location.png
Machine finds Fiducial and looks OK. 

But 
2) if I try to HOME machine - Homing operation starts but than no bouncing beck from end-stops X &Y is happening and error is shown:
Error Com4 IO.png

Thanks
Mike

Mike Menci

unread,
Nov 15, 2021, 11:46:35 AM11/15/21
to OpenPnP
Several tests TRACE enclosed ( look at latest only please!) 
Mike

TRACE_Homing.txt

mark maker

unread,
Nov 15, 2021, 11:53:03 AM11/15/21
to ope...@googlegroups.com

Please send the full log.

--
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/c5b69bd9-c374-4a27-b292-1cc3fbe54d9fn%40googlegroups.com.

Mike Menci

unread,
Nov 15, 2021, 12:03:30 PM11/15/21
to OpenPnP
Mark 
Full is ?? 
Enclosed Global Error / Log Debug ??
Mike

Error_Debug.txt

mark maker

unread,
Nov 15, 2021, 12:34:34 PM11/15/21
to ope...@googlegroups.com

No I mean the full length log, i.e. before the visual homing happens.

See your log directory:

https://github.com/openpnp/openpnp/wiki/FAQ#where-are-configuration-and-log-files-located

Mike Menci

unread,
Nov 15, 2021, 12:50:35 PM11/15/21
to OpenPnP
OK- this one than:
OpenPnP.0.log

Mike Menci

unread,
Nov 15, 2021, 3:27:41 PM11/15/21
to OpenPnP

Hmm - Error is from COM4 which is Schultz feeders controller NanoEvery/ not COM3 = Smoothie. How-come feeder controller is stopping homing on main Smoothie?

mark maker

unread,
Nov 16, 2021, 2:49:50 AM11/16/21
to ope...@googlegroups.com

Hi Mike

The connect is all-or-nothing. If one driver is failing, it will also tear down the other. I had to add this, because otherwise you could get hopelessly entangled communications states, that are invisible to the user (remember, I'm testing with three controllers).

You need to make sure the communication with the feeder controller is OK.

Obviously, for a productive machine, all-or-nothing is the only sensible way. But I guess this might sometimes be inconvenient for an unfinished the machine. Unfortunately, there is currently no way to "officially" disable a driver. But I use the following trick:

  • Set to TCP and use the String GcodeServer (case sensitive) as the IP Address. It will connect to an internal simulated G-code controller, so it is happy until you can sort out the problem.
I will keep this in mind to add a way to disable a driver temporarily. It should then only throw an error when you actually try to use it, in your case only when you try to feed.

_Mark

Mike Menci

unread,
Nov 16, 2021, 4:11:57 AM11/16/21
to OpenPnP
Hi Mark, 
I followed your advice and switched to TCP on Schultz driver and  error no connection came out - no control possible and no connection at all...
Than I switched beck to Schultz serial and now homing and all works normal - so it could be a small bug ?
I am sending you Log ant trace files from this morning enclosed - I hope it might help you to see where the problem is 
Thanks for your continuous support Mark.

working homing TRACE.txt
OpenPnP.0.log
OpenPnP.1.log

mark maker

unread,
Nov 16, 2021, 4:49:53 AM11/16/21
to ope...@googlegroups.com

Have you set   GcodeServer as IP Address? Make sure it is exactly spelled like here.

_Mark

Mike Menci

unread,
Nov 16, 2021, 7:13:09 AM11/16/21
to OpenPnP
Hi 
Tested as per your instruction - homing starts - but it does not reach HOME location...
GcodeServer.png
Trace enclosed
Mike

Trace_GServer.txt

mark maker

unread,
Nov 16, 2021, 8:20:16 AM11/16/21
to ope...@googlegroups.com

OK, there seems to be a bug in the GcodeServer. It does not "OK" empty lines. But that does not seem to be the real problem.

You need to test homing  using the GcodeDriver console. If I were to guess, you don't have the end-switches / homing configured right in Smoothieware config.txt.

_Mark

mark maker

unread,
Nov 16, 2021, 8:32:02 AM11/16/21
to ope...@googlegroups.com

No, there is no bug in GcodeServer, i.e. it is happy with empty commands. It seems you have a  COMMAND_CONFIRM_REGEX, that does not match the one of GcodeServer.

But like I said, this is only a distraction. The real issue here, is that homing is not working right on the G-code level i.e. outside of OpenPnP.

_Mark

Mike Menci

unread,
Nov 16, 2021, 10:18:49 AM11/16/21
to OpenPnP
Mark 
Homing was working for over a year as it is in Config....
Herewith enclosed my config smoothie file  and Command Reg -screen shot
Please review
Mike

config.txt
CommandRegex.png

mark maker

unread,
Nov 16, 2021, 10:29:24 AM11/16/21
to ope...@googlegroups.com

Hmmm.. well, I don't understand, why there is almost no delay here:

2021-11-16 13:05:35.796 GcodeDriver DEBUG: [serial://COM3] >> G28 X0 Y0 B0 C0; Home all axes, -1
2021-11-16 13:05:36.985 GcodeDriver$ReaderThread TRACE: [serial://COM3] << ok
2021-11-16 13:05:36.986 GcodeDriver TRACE: [serial://COM3] confirmed G28X0Y0B0C0
2021-11-16 13:05:36.987 GcodeDriver DEBUG: [serial://COM3] >> M400, -1
2021-11-16 13:05:36.988 GcodeDriver$ReaderThread TRACE: [serial://COM3] << ok
2021-11-16 13:05:36.988 GcodeDriver TRACE: [serial://COM3] confirmed M400

Does it really home in a mere 1.2s?

You said earlier:

> Homing operation starts but than no bouncing beck from end-stops X &Y is happening

Is this still true?

If yes, I don't see how this problem can be inside OpenPnP.

_Mark

Mike Menci

unread,
Nov 16, 2021, 11:24:52 AM11/16/21
to OpenPnP
Mark - you can see homing working here in this old video from Aug.2020 - https://www.youtube.com/watch?v=CbqQ_7yrL24 
but if Head is near the homing point than distance to home is closer and can be faster-correct? 

Yes - it is still happening - not bouncing beck from X & Y end-stop to reach fiducial and look for center of fiducial.

Mike

mark maker

unread,
Nov 16, 2021, 12:34:38 PM11/16/21
to ope...@googlegroups.com

What exactly do you mean by "not bouncing back"? Does it move against the switch, until it clicks, and then slowly bounce back until it clicks again? Or not?

_Mark

Mike Menci

unread,
Nov 16, 2021, 2:42:13 PM11/16/21
to OpenPnP
See this screen shot 
Head Moves to X = 0 and Y = 0 end-stops and stays here. (without continuing moving to look for Fiducial at):
TCP-GcodeServer 50026 timeout.png
- Head should move to X= 92  / Y = 42 and look for fiducial --- this is not happening. 
and after 5-10 sec this error is now coming up 
Mike


Mike Menci

unread,
Nov 16, 2021, 2:48:08 PM11/16/21
to OpenPnP
Than TCP - window I close 
and perform Visual test and it does the test !
Visual test works.png
Strange..

Mike Menci

unread,
Nov 16, 2021, 2:56:03 PM11/16/21
to OpenPnP
It seam I got it now to work by accepting I & S: 
I&S - solved.png

Mike Menci

unread,
Nov 16, 2021, 3:00:12 PM11/16/21
to OpenPnP
But now Port changes to: 
TCP - port 50350.png
GcodeServer Port.png
I have to change it beck to 23.... to work...

mark maker

unread,
Nov 17, 2021, 2:57:18 AM11/17/21
to ope...@googlegroups.com

Can you fix and restore the real feeder controller connection?

If not, you need to set the default

COMMAND_CONFIRM_REGEX

to match the GcodeServer response for the interim. Just delete it an let I & S propose the correct one.

_Mark

Mike Menci

unread,
Nov 17, 2021, 6:39:17 AM11/17/21
to OpenPnP
Mark - can you please advice  on driver sttings MOTION ?? : Driver Settings-OpenPnP.png
I still get errors with connecting to Schultz feeders - see enclosed

Feeders-OpenPnP - Untitled.job.png
Truble Comm Feeders.png

mark maker

unread,
Nov 17, 2021, 8:48:36 AM11/17/21
to ope...@googlegroups.com

This is irrelevant.

Have you let I&S propose the COMMAND_CONFIRM_REGEX?

What happens afterwards? Log?

_Mark

Mike Menci

unread,
Nov 17, 2021, 9:15:42 AM11/17/21
to OpenPnP
Hello - it seams I am running in circle with I & S 
Port keeps changing to very high No. : 52604 and I need to set it beck to 23
I & S _PnP.pngPort _52604.png
Enclosed Logs..
Mike

OpenPnP.0.log
OpenPnP.2.log
OpenPnP.3.log
OpenPnP.1.log
Log Trace.txt

mark maker

unread,
Nov 17, 2021, 10:33:08 AM11/17/21
to ope...@googlegroups.com

Don't bother about the port. It is irrelevant and automatically set.

In the log everything looks good at first. Does the head really not move?

_Mark

Mike Menci

unread,
Nov 17, 2021, 11:17:37 AM11/17/21
to OpenPnP
Mark -
I wrote here that I got the Head & Homing working yesterday : https://groups.google.com/g/openpnp/c/BecONfe_AYE/m/MDx9ngMdAAAJ

"Don't bother about the port. It is irrelevant and automatically set"    This than does not work - becouse I need to set it to No. 23 if I want Homing to work. It changes - so I need to set it to 23 if I want to Jog or home. .... 

The problem is now that Schultz feeders do not respond to feed the Nozzles if I run a Job- but the Job complets - see log enclosed
Now as well COM3 (Smoothie) stoped responding, ........ 
Job_Trace.txt

Mike Menci

unread,
Nov 17, 2021, 11:28:50 AM11/17/21
to OpenPnP
I tested this again: 
"Don't bother about the port. It is irrelevant and automatically set"    This than does not work - becouse I need to set it to No. 23 if I want Homing to work. It changes - so I need to set it to 23 if I want to Jog or home. .... 
It works with other No. as well    - Sorry.
Port-OpenPnP - 53567.job.png
But Feeders do not respond at all at Job ...

Mike Menci

unread,
Nov 17, 2021, 11:42:56 AM11/17/21
to OpenPnP
Mark, 
I suspect the error could be in enclosed Gcode ?
Mike

Schultz Gcode.txt

mark maker

unread,
Nov 17, 2021, 12:48:16 PM11/17/21
to ope...@googlegroups.com

Are you sure you are not mixing things up?

It should be like so:

  1. You have your motion controller on serial and COM3.
  2. You have your Schulz controller temporarily on tcp and GcodeServer IP Address.

Obviously, the feeder will then not work. If you want it to work, you need to set it back to serial and find the right COM port.

_Mark

Reply all
Reply to author
Forward
0 new messages