Read Output pin state

OwenD

The answer was provided.
The gcode is the object model query

https://github.com/Duet3D/RepRapFirmware/wiki/Object-Model-Documentation#overview

You should also search on duet meta commands.

However...
You said you're using openPNP
How does that communicate with the Duet?
I thought it used its own software.
It will make a difference whether it runs completely on the Duet, or whether it's connected via a USB cable or uses TCP socket connection.

wayneosdias

@owend
OpenPnp is the motion planner, it is connected via native USB.

OwenD

@wayneosdias
So the questions becomes from where do you need the information extracted and passed to?

What are you trying to achieve?

If the query/answer will be used purely on the duet, the you can use the object model and conditional gcode to do it.

If you need to pass the gpio state back to your external motion planner via usb then I suspect something like M118 will need to be used, however I have no direct knowledge of openPNP

EDIT:
Can you use something like

M118 P1 S{state.gpOut[3].value} L0

This should send the IO state via USB

wayneosdias

@owend said in Read Output pin state:

M118 P1 S{state.gpOut[3].value} L0

First thanks for everyones help thus far;
What Im trying to achieve is a 'component feed' as follows;

machine XY's head mounted drag pin to component tape hole
machine actuates drag pin
drag pin is in down position inserted into tape hole
machine 'drags' tape in X direction to feed next component into postion
drag pin is de activated
machine XY's head mounted nozzle to component
... and completes the pick process.

In this process there is an issue where the drap pin may be stuck down despite being de activated. To prevent XY motion in the case of a stuck drag pin there is a dragpin sensor. In Openpnp his is referred to 'Axis Interlock'. We dont dont want XY with a down drag pin UNLESS the dragpin is actuated to do so as in a feed event.

Boiling this all down is;

we want XY movement when the drag pin is actuated and sensor states it so
we dont want XY movment when the drag pin is de activated and sensor
states it so

Circling back to the original question. What Gcode can I use to get the current output state of an output pin?

OwenD

@wayneosdias
Either you are not actually reading any of the responses given, or there is some sort of communication or translation issue.

You have been told several times that the Gcode is

state.gpOut[3].value

where 3 is the sensor number of an output pin.

or

sensors.gpIn[3].value

where 3 is the sensor number of an input pin

If your sensor is connected to the duet, then it is an INPUT

Your Gcode needs to contain something like

while sensors.gpIn[3].value = 1
    G4 P500 ; if the sensor level is high, go into a wait loop

You are unlikely to get working code unless you find someone who also uses openPNP, but you have been provided ample information to work it out.r

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...