Read Output pin state

dc42

@wayneosdias said in Read Output pin state:

I tried this

state.gpOut[3].value
Error: Bad command: stategpOut[3]value
ok

Try this:

echo state.gpOut[3].value

wayneosdias

@dc42 said in Read Output pin state:

echo state.gpOut[3].value

Hey dc
I tried but still get...

> echo state.gpOut[3].value
Error: Bad command: echostategpOut[3]value
ok

wayneosdias

@owend
I have read and tried all responses thoroughly before each and every response. I think you may be having difficulty understanding the question. But it's stated pretty explicitly.

Stephen6309

@wayneosdias If you want the pwm value, use state.gpOut[3].pwm. You can't get undefined items.

wayneosdias

@stephen6309 said in Read Output pin state:

state.gpOut[3].pwm

Thanks Stephen,
I cant get that to work either

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

Stephen6309

@wayneosdias I don't have any gpio pins defined, but 0 is there.

Currently on rrf 3.4.0rc2

Sending in the DWC Console:
echo state.gpOut[0].pwm

This shows up in the DWC Console:
echo state.gpOut[0].pwm
0.0736

Object Model in DWC shows 0.07

gloomyandy

@wayneosdias What program are you using to send those commands? It looks like something is removing some of the characters before they are sent to the Duet.

wayneosdias

@stephen6309 Hey Stephen
I need response via USB to Openpnp. DWC is connected via ethernet

wayneosdias

@gloomyandy
Hey Andy its Openpnp

Stephen6309

@wayneosdias Then you need to determine why it's removing spaces and periods from the command.

wayneosdias

@stephen6309
I think you got it. When I view the trace logs of the comms between Openpnp and the hardware, all commands sent from Openpnp the spaces are trimmed...
Ill dtry again and post a log snippet.

wayneosdias

@stephen6309

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