Connection error
Shai
mark maker
Log, please.
--
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/e955e9cc-a22e-4c21-83fd-3665ae1141dfn%40googlegroups.com.
Shai
mark maker
Are you sure you don't have two drivers?
Please send the machine.xml too
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/fbc38080-fcd0-43f4-a28b-d0e905b0b86an%40googlegroups.com.
Shai
mark maker
> Openpnp requires to connect to all
controllers/drivers?
Yes, it's "all or nothing". Enabling the machine means connecting
all controllers. If one fails to connect, it will disconnect the
ones already connected. I decided to introduce this, after my
tests with three controllers showed that connecting/disconnecting
only half of them created extremely hard to diagnose problems and
deadlocks due to multi-threading (each driver has a writer and
reader thread, the task system has a machine thread, they all need
to interact smoothly through queues).
If you have problems with one controller and want to temporarily
not connect it, use the GcodeServer trick, i.e. switch to tcpip
and set the address to "GcodeServer" (without the quotes,
case sensitive). It will then use a simulated internal controller,
so OpenPnP can still at least send commands somewhere without
immediately failing. It can only simulate a typical motion Gcode
controller, but for most feeder controllers that's still good
enough at least to connect and home, which is typically all you
need such "work in progress" scenarios.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/6a088fa7-b214-4bee-8f07-b3c5b92db936n%40googlegroups.com.
Shai
mark maker
No RapidFeeder code was changed since then, to the best of my
knowledge.
But looking at your machine.xml, I guess this is the star head design, right? So the Z axis is wired in a very peculiar way.
Notably, the Z axis of the camera is also the same physical Z
axis as all the nozzles share!
Is this correct? Does your down-looking camera move up/down physically
with Z? (its a long time I last looked at the head design, I don't
remember)
If NO, please assign your virtual axis.
If YES, I'm not sure OpenPnP is fully prepared to handle this yet. A special kind of 3D units per pixel handling would be needed, where the units per pixel do not change with Z, but the camera position does, i.e. the camera-to-subject distance remains constant. Many Z movements are then expected, as the camera is then supposed to focus to the subject each time, here the barcode Z. If the camera also shares the Z with the nozzles (as your machine.xml says), this will incur many Safe Z movements and slow machine operation. OpenPnP assumes this to be a virtual axis, so there is no particular effort in the code to minimize these movements.
For a physical Z camera axis that is shared with nozzles' Z, I
assume you would need a mapped
transformation axis at least, so that camera Z range is
shifted completely inside the Safe Z Zone, so at least the Z does
not need to move to safe Z between each camera shot. Now that I
write all that, I think I already explained that to you before...
?
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/b6efc3dc-3498-4aa6-a95d-2fd6e428d748n%40googlegroups.com.
mark maker
Btw, please open a new thread for this discussion, it has nothing to do with a connection error 😎
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/a22e86d5-7ec8-615d-6157-ed0aabb4efd2%40makr.zone.