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.
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
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/c6d90572-3aaa-4407-a358-9c46bc96f0dcn%40googlegroups.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:
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/7b5461f0-2405-48c1-800e-da71e8d7c0e2n%40googlegroups.com.
Have you set GcodeServer as IP
Address? Make sure it is exactly spelled like here.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/36db3629-1e95-4066-a254-887c6d8468dan%40googlegroups.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
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/316187bd-dad0-49f6-9e94-8609587905d9n%40googlegroups.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
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/674316b7-e4ff-2620-bd33-85a46fcb0765%40makr.zone.
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
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/f81ba4db-9c6b-44fd-9e4d-14b8c3d7487bn%40googlegroups.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
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/068b4d3f-15d8-4549-aceb-32bad8a26f89n%40googlegroups.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
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/e5a41d56-87ef-4153-a730-bfcc2d022545n%40googlegroups.com.
This is irrelevant.
Have you let I&S propose the COMMAND_CONFIRM_REGEX?
What happens afterwards? Log?
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/95893590-111a-4bb1-8263-f06b830838edn%40googlegroups.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
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/fdc48e14-c186-4583-9dd6-da8d25af71c9n%40googlegroups.com.
Are you sure you are not mixing things up?
It should be like so:
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
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/98b22707-eb7b-4e49-8c83-a0a610bcb06cn%40googlegroups.com.