Read Output pin state

wayneosdias

Openpnp Gcode console...

> M118 P1 S{state.gpOut[3].pwm} L0
Error: M118: unknown value 'stategpOut^pwm'
ok

Openpnp Trace log...

2022-02-27 10:42:30.123 GcodeAsyncDriver DEBUG: serial://COM13 commandQueue.offer(M118 P1 S{state.gpOut[3].pwm} L0, 5000)...
2022-02-27 10:42:30.124 GcodeAsyncDriver$WriterThread TRACE: [serial://COM13] >> M118P1S{stategpOut[3]pwm}L0
2022-02-27 10:42:30.126 GcodeDriver$ReaderThread TRACE: [serial://COM13] << Error: M118: unknown value 'stategpOut^pwm'
2022-02-27 10:42:30.126 GcodeDriver$ReaderThread TRACE: [serial://COM13] << ok

spaces are being trimmed. I guess I need to take this to the Openpnp guys.

Thanks for everyones help

wayneosdias

@stephen6309
I just confirmed in Realterm a basic serial interface

M118 P1 S{state.gpOut[3].pwm} L0 [\n]

Works and responds

0.30                                                                  
     ok

But not in Openpnp 2nd trimming spaces. I'm not sure why RRF hiccups on this as the following works fine;

2022-02-27 11:21:16.287 ReferenceActuator DEBUG: DragPin PulseOn.actuate(false)
2022-02-27 11:21:16.287 GcodeAsyncDriver DEBUG: serial://COM13 commandQueue.offer(M42 P3 S0, 5000)...
2022-02-27 11:21:16.287 GcodeAsyncDriver DEBUG: serial://COM13 commandQueue.offer(G4 P100, 5000)...
2022-02-27 11:21:16.287 GcodeAsyncDriver$WriterThread TRACE: [serial://COM13] >> M42P3S0
2022-02-27 11:21:16.288 GcodeAsyncDriver$WriterThread TRACE: [serial://COM13] >> G4P100
2022-02-27 11:21:16.288 GcodeDriver$ReaderThread TRACE: [serial://COM13] << ok
2022-02-27 11:21:16.388 GcodeDriver$ReaderThread TRACE: [serial://COM13] << ok

Again spaces trimmed but RRF processes it just fine. Is there a setting within RRF to accept this or will this be an Openpnp work around?

gloomyandy

@wayneosdias It's not just spaces being removed, it has also dropped the "." in "[3].pwm"

wayneosdias

@gloomyandy
You're right.
Just for giggles I tried this;

2022-02-27 11:32:30.996 GcodeAsyncDriver DEBUG: serial://COM13 commandQueue.offer("M118 P1 S{state,gpOut[3],pwm"} L0, 5000)...
2022-02-27 11:32:30.996 GcodeAsyncDriver$WriterThread TRACE: [serial://COM13] >> "M118P1S{state,gpOut[3],pwm"}L0
2022-02-27 11:32:30.998 GcodeDriver$ReaderThread TRACE: [serial://COM13] << Error: Bad command: "M118P1S{state,gpOut[3],pwm"}L0
2022-02-27 11:32:30.998 GcodeDriver$ReaderThread TRACE: [serial://COM13] << ok

It trims'.' and spaces, but not commas. I'll ask the Openpnp guys about it...

wayneosdias

@gloomyandy @Stephen6309
I have to turn off gcode compression within Openpnp and everything works. I dunno what kind of a performance hit Ill have if any. I believe the Full 3rd order motion planner is pretty comm intensive. Thanks for the help guys.

alankilian

@wayneosdias

You can check the "Backslash Escaped Characters?" box and by-hand enter all the characters that got compressed into the string if you want to.

That way you can still run compressed.

https://groups.google.com/g/openpnp/c/w5uYStlntz0

wayneosdias

@alankilian
Yes! Thanks Alan!

M118 P1 S{state\u002EgpOut[3]\u002Epwm} L0

Works perfectly with GCode Compression

2022-02-27 13:07:50.156 GcodeAsyncDriver DEBUG: serial://COM13 commandQueue.offer(M118 P1 S{state\u002EgpOut[3]\u002Epwm} L0, 5000)...
2022-02-27 13:07:50.158 GcodeAsyncDriver$WriterThread TRACE: [serial://COM13] >> M118 P1 S{state.gpOut[3].pwm} L0
2022-02-27 13:07:50.158 GcodeDriver$ReaderThread TRACE: [serial://COM13] << 0.00
2022-02-27 13:07:50.159 GcodeDriver$ReaderThread TRACE: [serial://COM13] << ok

Thanks Again Alan!

alankilian

@wayneosdias

I'm thrilled that you are taking the time to work Duet into the OpenPNP world.

Are you sure you turned compression back on?
Because I thought it compressed the spaces out also but it doesn't seem to be doing that.

wayneosdias

@alankilian
Yes its working with compression. Here is a snippet of my machine.xml with the setting emboldened. The full .xml file is several thousand lines long;

driver class="org.openpnp.machine.reference.driver.GcodeAsyncDriver" id="DRV16cc6c1da8ebf1f8" name="GcodeAsyncDriver" motion-control-type="Simulated3rdOrderControl" communications="serial" connection-keep-alive="false" sync-initial-location="false" units="Millimeters" max-feed-rate="100000" backlash-offset-x="-1.0" backlash-offset-y="-1.0" backlash-offset-z="0.0" backlash-offset-r="0.0" non-squareness-factor="0.0" backlash-feed-rate-factor="0.1" timeout-milliseconds="5000" connect-wait-time-milliseconds="3000" visual-homing-enabled="true" backslash-escaped-characters-enabled="false" remove-comments="false" compress-gcode="true" logging-gcode="true" supporting-pre-move="false" using-letter-variables="true" infinity-timeout-milliseconds="60000" writer-polling-interval="100" writer-queue-timeout="60000" max-commands-queued="1000" confirmation-flow-control="false" reported-location-confirmation="true" interpolation-max-steps="32" interpolation-jerk-steps="4" interpolation-time-step="0.001" interpolation-min-step="16"

Config

Console

Thanks. Duet is working very well w Openpnp thus far. I started a Duet Wiki page under Openpnp. All add this info for others as well. RRF config via SD is so much easier to get Openpnp configured correctly vs Smoothieware that needs you to rebuild and flash with each config change.

There is a lot of hesitancy to move to Openpnp from propriety PnP controllers because generating the machine.xml (Openpnp config) is long and complex. The Duet/RRF make scratch building the machine.xml much more straight forward.

Again thanks

alankilian

@wayneosdias said in Read Output pin state:

backslash-escaped-characters-enabled="false"

I'm sure you know what you're doing, and I'm also SURE I DO NOT, but this doesn't match your graphics, so maybe just check to be sure?

I do know I've wasted so much time when I update something and forget to type Make before testing, or I edited and didn't save a change, so I'm an idiot.

wayneosdias

@alankilian
Sorry, yes you're correct again
The xml doesn't update until File>Save>Configuration. Meaning the GUI changes don't automatically update the xml and I blindly copied it without saving first.

So just for clarity I Saved the GUI settings, closed Openpnp, restarted Openpnp and now;

xml
driver class="org.openpnp.machine.reference.driver.GcodeAsyncDriver" id="DRV16cc6c1da8ebf1f8" name="GcodeAsyncDriver" motion-control-type="Simulated3rdOrderControl" communications="serial" connection-keep-alive="false" sync-initial-location="false" units="Millimeters" max-feed-rate="100000" backlash-offset-x="-1.0" backlash-offset-y="-1.0" backlash-offset-z="0.0" backlash-offset-r="0.0" non-squareness-factor="0.0" backlash-feed-rate-factor="0.1" timeout-milliseconds="5000" connect-wait-time-milliseconds="3000" visual-homing-enabled="true" backslash-escaped-characters-enabled="true" remove-comments="false" compress-gcode="true" logging-gcode="true" supporting-pre-move="false" using-letter-variables="true" infinity-timeout-milliseconds="60000" writer-polling-interval="100" writer-queue-timeout="60000" max-commands-queued="1000" confirmation-flow-control="false" reported-location-confirmation="true" interpolation-max-steps="32" interpolation-jerk-steps="4" interpolation-time-step="0.001" interpolation-min-step="16"

GUI

Its all working

wayneosdias

@dc42 @alankilian @gloomyandy @OwenD @SIam @Stephen6309
Thanks again.

Now that I have M118 working within Openpnp with GCode compression via the Backslash option I have changed my other analog sensor queries;

Initially using M308 was pretty verbose with 138 total char count

>> M308S0
<< Sensor 0 (Pressure_1) type Linear analog using pin temp0, reading 1996.0, last error: success, unfiltered, range 0.0 to 4095.0

Vs now using M118 a total char count of 50

>> M118P1S{sensors.analog[0].lastReading}
//actual Opnepnp syntax w compression and back slash
// M118 P1 S{sensors\u002Eanalog[0]\u002ElastReading}
<< 1996.0

Thanks Wayne

OwenD

@wayneosdias
Glad it's all working.
Be interesting to see a video of it in operation

wayneosdias

@owend
Will do, I need to get the mechanicals back together first.
If you dont know what this is, it's the aftermath drag pin machine crash. The pin with the bent tip slides up and down within the blue coil of the selenoid with the bent frame.

I hope to get fixed tonight and put some of my new and improved RRF commands to work

Thanks again.

wayneosdias

Heres a quick vid of the process.
pick_2edOjyQd.mp4

droftarts

@wayneosdias Hi, is it okay to add a link to your wiki page on our wiki page here? https://docs.duet3d.com/User_manual/Machine_configuration/Configuration_OpenPnP

Ian

wayneosdias

@droftarts
Yes absolutely. I do need to make some tweeks to the wiki as I have been making changes but haven't been updating the wiki. I'll spend some time tonight to tiding things up a bit.

I don't want to spread any bad info so if you see anything that is not best practice please let me know.

Lastly, just to put the original topic to bed, M118 is the best method for retrieving input/output/analog values from Duet using GCode correct? Best meaning timely and succinct.

droftarts

@wayneosdias Great, thanks.

For sending messages to USB, I guess M118 is going to be the most useful; I actually can't think of any other way to do it. If you wanted to send to DWC or PanelDue (but I don't think you do), use M291 instead.

Ian

wayneosdias

@droftarts
Ok good to know, for Openpnp its USB/serial or tcp.

wayneosdias

@droftarts
Ive updated the wiki, it is current. Feel free to post the link
https://github.com/openpnp/openpnp/wiki/Duet3D-Openpnp-Example