Little Bit Trouble with Schulz Feeder - Need Help - behaviour little strange

[Andy PausB]

Hello all together

I build up and maschine works. 

Now i build up the Schultz controller incl. the Controller Board from here: https://github.com/openpnp/openpnp/wiki/SchultzFeeder-and-SlotSchultzFeeder

It works. I added the driver. I added the feeder by script. Then i attached physical 2 Feeder (2 times 2Lane Feeder). I Get the ID and they where found. I Use Connector one for 2Lane Feeder1 and Connector 2 for another 2Lane Feeder.  The have different IDs, of course. 

All works but: When i switch from one Feeder to the next in the Feeders menue (testing between, Pre Pick and so on) each time i toggle between feeders I get Warning: "Actuator "SchultzGetID" read Error: No matching responses found."

This comes after the timeout of the controller. Then i just Push again "GetID" and voila -> It works and finds ID. 

This also is when i switch between the the Lanes of the same Feeder. Very curious.

What is wrong ? 

Thank you a lot. Without the help from your side i had still gave up........

[Mike Menci]

Andy can you post PnP Trace log ? That would help 

Mike

[Andy PausB]

Yes of course. 

Machine started. 

This comes up when ok detected: Means i push on the Feeder Lane 1

2022-08-29 23:50:53.965 GcodeDriver DEBUG: [serial://COM3] >> M608N0, 500
2022-08-29 23:50:53.965 GcodeDriver DEBUG: [serial://COM3] >> M610N0, 500
2022-08-29 23:50:53.965 GcodeDriver$ReaderThread TRACE: [serial://COM3] << M608N0
2022-08-29 23:50:53.965 GcodeDriver$ReaderThread TRACE: [serial://COM3] << buffer 0
2022-08-29 23:50:53.980 GcodeDriver$ReaderThread TRACE: [serial://COM3] << command found: M608
2022-08-29 23:50:53.980 GcodeDriver$ReaderThread TRACE: [serial://COM3] << send read EEPROM command
2022-08-29 23:50:53.980 GcodeDriver$ReaderThread TRACE: [serial://COM3] << 0 sending: 3 17 1 0 1B
2022-08-29 23:50:54.012 GcodeDriver$ReaderThread TRACE: [serial://COM3] << ok 4 MM
2022-08-29 23:50:54.012 GcodeDriver TRACE: [serial://COM3] confirmed M608N0
2022-08-29 23:50:54.012 GcodeDriver$ReaderThread TRACE: [serial://COM3] << M610N0
2022-08-29 23:50:54.012 GcodeDriver TRACE: actuatorRead response: ok 4 MM
2022-08-29 23:50:54.012 ReferenceActuator DEBUG: SchultzGetPitch.readWithParameter(0.0): 4 MM
2022-08-29 23:50:54.012 GcodeDriver$ReaderThread TRACE: [serial://COM3] << buffer 1
2022-08-29 23:50:54.012 GcodeDriver$ReaderThread TRACE: [serial://COM3] << command found: M610
2022-08-29 23:50:54.012 GcodeDriver$ReaderThread TRACE: [serial://COM3] << send read EEPROM command
2022-08-29 23:50:54.012 GcodeDriver$ReaderThread TRACE: [serial://COM3] << 0 sending: 3 17 1 0 1B
2022-08-29 23:50:54.043 GcodeDriver$ReaderThread TRACE: [serial://COM3] << ok ID: 279L
2022-08-29 23:50:54.043 GcodeDriver TRACE: [serial://COM3] confirmed M610N0
2022-08-29 23:50:54.043 GcodeDriver TRACE: actuatorRead response: ok ID: 279L
2022-08-29 23:50:54.043 ReferenceActuator DEBUG: SchultzGetID.readWithParameter(0.0): 279L
2022-08-29 23:50:54.043 GcodeDriver DEBUG: [serial://COM3] >> M603N0, 500
2022-08-29 23:50:54.043 GcodeDriver$ReaderThread TRACE: [serial://COM3] << M603N0
2022-08-29 23:50:54.043 GcodeDriver$ReaderThread TRACE: [serial://COM3] << buffer 2
2022-08-29 23:50:54.043 GcodeDriver$ReaderThread TRACE: [serial://COM3] << command found: M603
2022-08-29 23:50:54.059 GcodeDriver$ReaderThread TRACE: [serial://COM3] << send read EEPROM command
2022-08-29 23:50:54.059 GcodeDriver$ReaderThread TRACE: [serial://COM3] << 0 sending: 3 17 1 0 1B
2022-08-29 23:50:54.074 GcodeDriver$ReaderThread TRACE: [serial://COM3] << ok Feed count: 0
2022-08-29 23:50:54.074 GcodeDriver TRACE: [serial://COM3] confirmed M603N0
2022-08-29 23:50:54.074 GcodeDriver TRACE: actuatorRead response: ok Feed count: 0
2022-08-29 23:50:54.074 ReferenceActuator DEBUG: SchultzGetCount.readWithParameter(0.0): 0
2022-08-29 23:50:54.074 GcodeDriver DEBUG: [serial://COM3] >> M602N0, 500
2022-08-29 23:50:54.074 GcodeDriver$ReaderThread TRACE: [serial://COM3] << M602N0
2022-08-29 23:50:54.074 GcodeDriver$ReaderThread TRACE: [serial://COM3] << buffer 3
2022-08-29 23:50:54.090 GcodeDriver$ReaderThread TRACE: [serial://COM3] << command found: M602
2022-08-29 23:50:54.090 GcodeDriver$ReaderThread TRACE: [serial://COM3] << send status command
2022-08-29 23:50:54.090 GcodeDriver$ReaderThread TRACE: [serial://COM3] << 0 sending: 2 15 1 18
2022-08-29 23:50:54.090 GcodeDriver$ReaderThread TRACE: [serial://COM3] << ok getFeederStatus: feeder OK
2022-08-29 23:50:54.090 GcodeDriver TRACE: [serial://COM3] confirmed M602N0
2022-08-29 23:50:54.090 GcodeDriver TRACE: actuatorRead response: ok getFeederStatus: feeder OK
2022-08-29 23:50:54.090 ReferenceActuator DEBUG: SchultzGetStatus.readWithParameter(0.0): feeder OK

When switch to other lane "2" same feeder: Then Failure

2022-08-29 23:50:18.125 GcodeDriver DEBUG: [serial://COM3] >> M608N1, 500
2022-08-29 23:50:18.125 GcodeDriver DEBUG: [serial://COM3] >> M610N1, 500
2022-08-29 23:50:18.125 GcodeDriver$ReaderThread TRACE: [serial://COM3] << M608N1M610N1
2022-08-29 23:50:18.125 GcodeDriver$ReaderThread TRACE: [serial://COM3] << buffer 2
2022-08-29 23:50:18.125 GcodeDriver$ReaderThread TRACE: [serial://COM3] << command found: M608
2022-08-29 23:50:18.140 GcodeDriver$ReaderThread TRACE: [serial://COM3] << send read EEPROM command
2022-08-29 23:50:18.140 GcodeDriver$ReaderThread TRACE: [serial://COM3] << 0 sending: 3 17 2 0 1C
2022-08-29 23:50:18.156 GcodeDriver$ReaderThread TRACE: [serial://COM3] << ok 4 MM
2022-08-29 23:50:18.156 GcodeDriver TRACE: [serial://COM3] confirmed M608N1
2022-08-29 23:50:18.156 GcodeDriver TRACE: actuatorRead response: ok 4 MM
2022-08-29 23:50:18.156 ReferenceActuator DEBUG: SchultzGetPitch.readWithParameter(1.0): 4 MM
2022-08-29 23:50:18.156 GcodeDriver$ReaderThread TRACE: [serial://COM3] << buffer 3
2022-08-29 23:50:18.172 GcodeDriver$ReaderThread TRACE: [serial://COM3] << command found: M-1
2022-08-29 23:50:18.172 GcodeDriver$ReaderThread TRACE: [serial://COM3] << ok unknown or empty command ignored
2022-08-29 23:50:18.172 GcodeDriver TRACE: [serial://COM3] confirmed M610N1
2022-08-29 23:50:18.687 AbstractMachine TRACE: Exception caught, executing pending motion: java.lang.Exception: Actuator "SchultzGetID" read error: No matching responses found.

When i then push "GetID" it works and this comes up: (i also can start a Pick command, works also) 

2022-08-29 23:53:28.491 GcodeDriver DEBUG: [serial://COM3] >> M610N1, 500
2022-08-29 23:53:28.492 GcodeDriver$ReaderThread TRACE: [serial://COM3] << M610N1
2022-08-29 23:53:28.493 GcodeDriver$ReaderThread TRACE: [serial://COM3] << buffer 2
2022-08-29 23:53:28.497 GcodeDriver$ReaderThread TRACE: [serial://COM3] << command found: M610
2022-08-29 23:53:28.501 GcodeDriver$ReaderThread TRACE: [serial://COM3] << send read EEPROM command
2022-08-29 23:53:28.503 GcodeDriver$ReaderThread TRACE: [serial://COM3] << 0 sending: 3 17 1 0 1B
2022-08-29 23:53:28.519 GcodeDriver$ReaderThread TRACE: [serial://COM3] << ok ID: 279R
2022-08-29 23:53:28.528 GcodeDriver TRACE: [serial://COM3] confirmed M610N1
2022-08-29 23:53:28.528 GcodeDriver TRACE: actuatorRead response: ok ID: 279R
2022-08-29 23:53:28.528 ReferenceActuator DEBUG: SchultzGetID.readWithParameter(1.0): 279R

I tested it with a Place programm. It worked well, all Feeder work, no error message.

Maybe it is a "Schöner Wohnen Problem" ? !

Thank you very much.

[Andy PausB]

I am wondering about this line: 

2022-08-29 23:50:18.125 GcodeDriver$ReaderThread TRACE: [serial://COM3] << M608N1M610N1

May this cause the trouble ? 

[Bill Ruckman]

Yes, that is causing the problem.  The gcode parser cannot handle two commands on the same line.  I'm not sure why OpenPNP is doing this.

--Bill

--
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/a9c99fee-3b27-4b0d-995b-1c7f6db86ffbn%40googlegroups.com.

[Andy PausB]

Hi 

Is this a bug and how to find out ? 

[mark maker]

> I'm not sure why OpenPNP is doing this.

OpenPnP is not concatenating lines, ever. So this is likely a mis-configuration.

Please go have a look in the ACTUATE_COMMAND of that actuator.

Or send the machine.xml

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CALrF6L5kpGmacqLJEDdL4PC-HWUpaPDmpqEvtyEemnS15W-O6A%40mail.gmail.com.

[Bill Ruckman]

2022-08-29 23:50:18.125 GcodeDriver DEBUG: [serial://COM3] >> M608N1, 500
2022-08-29 23:50:18.125 GcodeDriver DEBUG: [serial://COM3] >> M610N1, 500

 Looking closer, I see that OpenPnP is not concatenating the commands, but it sent the second one without waiting for a response from the first one.  The controller should be able to handle this (it can buffer 4 commands).  Perhaps it can't handle that second command coming so soon after the first.  I am able to duplicate the issue, so I will take a look at it.  The good news is that it only seems to happen when viewing the configuration.

--Bill

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/1b82b6df-596f-8f15-3957-dd3e407f68d0%40makr.zone.

[Andy PausB]

Hi
That sounds very good. It is a very unfortable behaviour, because i try to install 10 Feeder. Every time is switch or make some changes, i have to wait timeout, and then comes error message up, which has to be pushed away. 

So if there will be a short workarround available, great !

The machine XML: I put in the original config file of the documentation, just copy and paste it. 

Now i have a different topic.

When i pick a part in Schultz feeder: The Nozzle drives to position, the shutter opens (part free), the nozzle gets down, then the shutter closes and after that the nozzle gets up !!

That means the shutter closes first and attaches  the part at the nozzle. (Then it is in a very uncomfortable position) 

Why ? Where can i configure the sequence ? 

Behaviur must: (My oppinion):

- Open Shutter

- Nozzle down

- Vac on

- Nozzle up

- Shutter close

- move smd part in Feeder one forward.

Thank you

[Bill Ruckman]

The shutter closes when the PostPick actuator is actuated (or automatically after 2 seconds).  Make sure you have Machine Coordination->Before Actuation? checked in the actuator configuration.

--Bill

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/41965f29-648f-4e1b-bd00-de65365a67ccn%40googlegroups.com.

[Andy PausB]

I found the problem. It was the speed of the Z axis and the waiting at end positions with 5000ms. I set this for test because of vacuum trouble.

Thanks for help.

[Andy PausB]

I am not shure, is there an update for this issue ? It is a liitle bit anoying when change and every time the failure pops up.

Thank youz 

bil...@gmail.com schrieb am Dienstag, 30. August 2022 um 18:35:14 UTC+2: