Actuator "SchultzGetPitch" read error: No matching responses found

[Lorenz Waldmüller]

Hello everyone,

we´re running into this error message when changing between feeder slots in the feeder menu. When manually getting the pitch it works without any problems. Has anyone had the same error message or knows what could be the problem?

Thanks in advance!

[Mike Menci]

Hi, 

I had similar problems and solved them by adding  USB 1500V Isolator ADUM3160

between Smothieboard and Shultz controller USB line. 

This one I have and still in use; https://www.amazon.de/-/en/Isolator-ADUM3160-Coupling-Protection-Isolation/dp/B0B7K84FGY/ref=sr_1_17?crid=1JSHX1IQMZXUE&keywords=5%2BV%2BUSB%2BPower%2BFilterplatine%2BRauschunterdr%C3%BCckung&qid=1682541493&sprefix=5v%2Busb%2Bpower%2Bfilter%2Bboard%2Bnoise%2Beliminator%2Caps%2C88&sr=8-17&th=1

I hope this will help. 

Mike

[Mike Menci]

Are you using  Arduino Nano Every as Schultz controller ?  Isolator can be tested as well before computer USB connector. 

Mike  

[Lorenz Waldmüller]

Hi, Yes we are using the Arduino Nano every and have it connected directly to the Pc running OpenPnP.

[Mark]

I thought I already sent a response here, but somehow it got loast.

Looking at the log, it seems you do not habe an ACTUATOR_READ_COMMAND defined for actuator SchultzGetPitch

Btw. please send log excerpts as text not as screenshots. There is a copy button in OpenPnP. It would allow me to quote the relevant section from it 😉.

_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 openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/2ccaac24-618f-4326-8fd3-c920c19bd6f1n%40googlegroups.com.

[Lorenz Waldmüller]

I think the ACTUATOR_READ_COMMAND should be definded because its working fine when getting the Pitch manually. The error just shows up when I try switching between the feeder slots.

In the Log you can see at first the manual command which works and then the automatic one which brings the error. Thanks in advance for the help!

2023-04-28 13:14:29.391 GcodeAsyncDriver DEBUG: serial://COM9 commandQueue.offer(M608N0, 15000)...
2023-04-28 13:14:29.391 GcodeDriver TRACE: [serial://COM9] confirmed M602N0
2023-04-28 13:14:29.392 GcodeAsyncDriver$WriterThread TRACE: [serial://COM9] >> M608N0
2023-04-28 13:14:29.392 GcodeDriver$ReaderThread TRACE: [serial://COM9] << M608N0
2023-04-28 13:14:29.393 GcodeDriver$ReaderThread TRACE: [serial://COM9] << buffer 1
2023-04-28 13:14:29.397 GcodeDriver$ReaderThread TRACE: [serial://COM9] << command found: M608
2023-04-28 13:14:29.401 GcodeDriver$ReaderThread TRACE: [serial://COM9] << send read EEPROM command
2023-04-28 13:14:29.403 GcodeDriver$ReaderThread TRACE: [serial://COM9] << 0 sending: 3 17 1 0 1B
2023-04-28 13:14:29.428 GcodeDriver$ReaderThread TRACE: [serial://COM9] << ok 2 MM
2023-04-28 13:14:29.428 GcodeDriver TRACE: actuatorRead response: ok 2 MM
2023-04-28 13:14:29.428 ReferenceActuator DEBUG: SchultzGetPitch.readWithParameter(0.0): 2 MM
2023-04-28 13:14:33.929 GcodeAsyncDriver DEBUG: serial://COM9 commandQueue.offer(M608N1, 15000)...
2023-04-28 13:14:33.929 GcodeDriver TRACE: [serial://COM9] confirmed M608N0
2023-04-28 13:14:33.930 GcodeAsyncDriver$WriterThread TRACE: [serial://COM9] >> M608N1
2023-04-28 13:14:33.930 GcodeAsyncDriver DEBUG: serial://COM9 commandQueue.offer(M610N1, 15000)...
2023-04-28 13:14:33.930 GcodeDriver$ReaderThread TRACE: [serial://COM9] << M608N1
2023-04-28 13:14:33.931 GcodeDriver$ReaderThread TRACE: [serial://COM9] << buffer 2
2023-04-28 13:14:33.935 GcodeDriver$ReaderThread TRACE: [serial://COM9] << command found: M608
2023-04-28 13:14:33.939 GcodeDriver$ReaderThread TRACE: [serial://COM9] << send read EEPROM command
2023-04-28 13:14:33.941 GcodeDriver$ReaderThread TRACE: [serial://COM9] << 0 sending: 3 17 2 0 1C
2023-04-28 13:14:33.965 GcodeDriver$ReaderThread TRACE: [serial://COM9] << ok 4 MM
2023-04-28 13:14:33.966 GcodeDriver TRACE: [serial://COM9] confirmed M608N1
2023-04-28 13:14:33.966 GcodeAsyncDriver$WriterThread TRACE: [serial://COM9] >> M610N1
2023-04-28 13:14:33.967 GcodeDriver$ReaderThread TRACE: [serial://COM9] << M610N1
2023-04-28 13:14:33.968 GcodeDriver$ReaderThread TRACE: [serial://COM9] << buffer 3
2023-04-28 13:14:33.972 GcodeDriver$ReaderThread TRACE: [serial://COM9] << command found: M610
2023-04-28 13:14:33.974 GcodeDriver$ReaderThread TRACE: [serial://COM9] << send read EEPROM command
2023-04-28 13:14:33.977 GcodeDriver$ReaderThread TRACE: [serial://COM9] << 0 sending: 3 17 1 0 1B
2023-04-28 13:14:34.001 GcodeDriver$ReaderThread TRACE: [serial://COM9] << ok ID: 8463R
2023-04-28 13:14:34.002 GcodeDriver TRACE: actuatorRead response: ok ID: 8463R
2023-04-28 13:14:34.002 ReferenceActuator DEBUG: SchultzGetID.readWithParameter(1.0): 8463R
2023-04-28 13:14:34.004 GcodeAsyncDriver DEBUG: serial://COM9 commandQueue.offer(M603N1, 15000)...
2023-04-28 13:14:34.004 GcodeDriver TRACE: [serial://COM9] confirmed M610N1
2023-04-28 13:14:34.005 GcodeAsyncDriver$WriterThread TRACE: [serial://COM9] >> M603N1
2023-04-28 13:14:34.005 GcodeDriver$ReaderThread TRACE: [serial://COM9] << M603N1
2023-04-28 13:14:34.006 GcodeDriver$ReaderThread TRACE: [serial://COM9] << buffer 0
2023-04-28 13:14:34.010 GcodeDriver$ReaderThread TRACE: [serial://COM9] << command found: M603
2023-04-28 13:14:34.014 GcodeDriver$ReaderThread TRACE: [serial://COM9] << send read EEPROM command
2023-04-28 13:14:34.016 GcodeDriver$ReaderThread TRACE: [serial://COM9] << 0 sending: 3 17 2 0 1C
2023-04-28 13:14:34.041 GcodeDriver$ReaderThread TRACE: [serial://COM9] << ok Feed count: 2635
2023-04-28 13:14:34.042 GcodeDriver TRACE: actuatorRead response: ok Feed count: 2635
2023-04-28 13:14:34.042 ReferenceActuator DEBUG: SchultzGetCount.readWithParameter(1.0): 2635
2023-04-28 13:14:48.930 MessageBoxes DEBUG: Error: java.lang.Exception: Actuator "SchultzGetPitch" read error: No matching responses found.
2023-04-28 13:15:06.126 GcodeAsyncDriver DEBUG: serial://COM9 commandQueue.offer(M602N1, 15000)...
2023-04-28 13:15:06.126 GcodeDriver TRACE: [serial://COM9] confirmed M603N1
2023-04-28 13:15:06.127 GcodeAsyncDriver$WriterThread TRACE: [serial://COM9] >> M602N1
2023-04-28 13:15:06.128 GcodeDriver$ReaderThread TRACE: [serial://COM9] << M602N1
2023-04-28 13:15:06.128 GcodeDriver$ReaderThread TRACE: [serial://COM9] << buffer 1
2023-04-28 13:15:06.132 GcodeDriver$ReaderThread TRACE: [serial://COM9] << command found: M602
2023-04-28 13:15:06.135 GcodeDriver$ReaderThread TRACE: [serial://COM9] << send status command
2023-04-28 13:15:06.137 GcodeDriver$ReaderThread TRACE: [serial://COM9] << 0 sending: 2 15 2 19
2023-04-28 13:15:06.147 GcodeDriver$ReaderThread TRACE: [serial://COM9] << ok getFeederStatus: No tape tension.  Tape may be broken
2023-04-28 13:15:06.147 GcodeDriver TRACE: actuatorRead response: ok getFeederStatus: No tape tension.  Tape may be broken
2023-04-28 13:15:06.148 ReferenceActuator DEBUG: SchultzGetStatus.readWithParameter(1.0): No tape tension.  Tape may be broken

[Mark]

Hi Lorenz,

I've seen some irregularities in the source code and fixed them.

Not entirely sure how the SchultzFeeder Wizards are used, and how exactly the bug can manifest itself, but these changes will (hopefully) remove the potential for races, and help you.

The fix is only available on the test version (allow a few minutes to deploy):

https://openpnp.org/test-downloads/

See the details:

https://github.com/openpnp/openpnp/pull/1550

Please test and report back. 💯

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/ebf903d3-a457-44d8-a9a5-a5a85bcdeda5n%40googlegroups.com.

[Lorenz Waldmüller]

Hi Mark,

thanks for the answer, I´m gonna test it next week and give you feedback!

Lorenz

[Lorenz Waldmüller]

Hi Mark,

the 'Get Pitch error seems to be solved. However when we want to open the scripts folder now the error message CoInitialize Ex() failed shows up.

Thanks for now, Lorenz

[Mark]

Please send the log

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/a1c0316f-917c-4659-9219-6164674cbfd4n%40googlegroups.com.

[Lorenz Waldmüller]

Sorry forgot to add it.

2023-05-02 13:41:36.167 MessageBoxes DEBUG: Error: java.io.IOException: Failed to open C:\Users\AVT23_Student_3\.openpnp2\scripts. Error message: CoInitializeEx() failed.

[Lorenz Waldmüller]

Hi Mark, 

not trying to bother you, but do you know what causes the issue of this error?

Thanks in advance for your help!

Lorenz

ma...@makr.zone schrieb am Dienstag, 2. Mai 2023 um 13:22:51 UTC+2:

[mark maker]

This is very likely unrelated (with SW we can never be sure), and discussed here:

https://groups.google.com/g/openpnp/c/0WTDo56vwow/m/2vurCpoKCAAJ

Maybe this evening I find some time to at least make a revert PR. But Jason (@vonnieda) would need to actually merge and deploy it.

Another option would be to go back to an older version of openpnp-capture, but then (if I understand correctly) the Apple Silicon and Raspi 4 users would not be happy.🙁

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/581683ec-bc47-4eef-abb1-fb9799bb43a4n%40googlegroups.com.

[Lorenz Waldmüller]

Hi,

are there any new informations on how we can go along to be able to use the scripts again?

Lorenz

[mark maker]

See here

https://groups.google.com/g/openpnp/c/0WTDo56vwow/m/HXTuEgQ1AgAJ

Jason likely did not find the time. I neither have access to the repo, nor the specific knowledge to fix it just for Windows.

All I can offer is to rollback the whole OpenPnpCaptureCamera to the old state. Apple Silicon users will not be happy. But I guess I will do that for the moment.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/4dd8c63f-84e5-4306-9bec-b4f3119778ccn%40googlegroups.com.

[ma...@makr.zone]

I've reverted the openpnp-capture-java dependency back to version 0.0.22, which is the version prior to 2023-03-20 22:24:13.

This will also roll back the native support for Mac Apple silicon and other stuff. But as some Windows users reportedly can't work at all, I think this is justified (Mac users can keep using the previous test version until it is resolved).

I hope this can soon be resolved, either by just rolling back the Windows specific code, or by fixing the bugs.

Somebody familiar with COM? HELP WANTED!

Details here:

https://github.com/openpnp/openpnp/pull/1558

_Mark

[mark maker]

New test version is deployed.

https://openpnp.org/test-downloads/

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/SFUnSoJpUig/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/255dc552-d26c-4311-830c-e2c8c1db37a7n%40googlegroups.com.

[Lorenz Waldmüller]

Hi,

unfortunately with the new Test Version the error still shows up when I try opening the scripts directory.

This is the Log with the error message.

2023-05-12 11:29:15.660 MessageBoxes DEBUG: Error: java.io.IOException: Failed to open C:\Users\AVT23_Student_3\.openpnp2\scripts. Error message: CoInitializeEx() failed.

Lorenz

[Mark]

Hi,

finally got around to test this on Windows.

It seems to be the new Java version packed with the install4j after all.

I tested the exact same Windows install with the packaged Java 17.0.7 (does not work) and with Microsoft build Java 11.0.18 (does work).

NOTE: as always, the error only pops up if an OpenPnpCaptureCamera is present. So it is related to COM, but I guess it is the JVM Desktop stuff which messes up. I will have to "rollback the rollback" on the openpnp-capture-java dependency. It does not seem to be the culprit after all 😭

For the install4j stuff, unfortunately, I must defer to @vonnieda (to perhaps replace Java 17 with 11?) 🙁

Lorenz, if you need a workaround soon, you could install Microsoft's Java 11 .msi

https://learn.microsoft.com/en-us/java/openjdk/download#openjdk-11

and install it

https://learn.microsoft.com/en-us/java/openjdk/install#install-via-msi

and then start openpnp using this command:

java --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.desktop/java.awt=ALL-UNNAMED --add-opens=java.desktop/java.awt.color=ALL-UNNAMED -jar "C:\Program Files\openpnp\openpnp-gui-0.0.1-alpha-SNAPSHOT.jar"

You can save it into an openpnp.cmd file for instance.

(A simple link did not work for me on 💩-Windows 11. They messed these basic Explorer capabilities up big time!)

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/9454cc84-cf9e-4fc9-ad9b-0f2be1a28426n%40googlegroups.com.

[Mark]

Ahh, here's the culprit:

https://bugs.openjdk.org/browse/JDK-8270269

So @vonnieda, it would likely help to package Java 11.

The infuriating thing is that this seems to be open for two years now!

https://stackoverflow.com/questions/67876108/desktop-browse-fails-with-jdk-17

The more infuriating thing is, that it is actually the 🤮 Microsoft tech, that causes this.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/ecd848c6-4bd4-da1d-768e-0e0809476cd8%40makr.zone.

[Mark]

Hi everybody,

The test version of OpenPnP now again contains the newest openpnp-capture-java library, as it turned out not to be the culprit.

Apple silicon and Raspi 4 users should be happy again.

Windows users please use the workaround as described here:

https://github.com/openpnp/openpnp/pull/1560

Allow some minutes to deploy.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/be29c15a-24a1-14d1-5225-4324e3f392ac%40makr.zone.