M950 GPIO Bug
-
I'm noticing a GCode bug on my Duet3D board. I'm running the following configuration:
FIRMWARE_NAME: RepRapFirmware for Duet 3 MB6HC FIRMWARE_VERSION: 3.1.1 ELECTRONICS: Duet 3 MB6HC v1.01 or later FIRMWARE_DATE: 2020-05-19b2So I'm using all 9 GPIO outputs to drive some valves and I have all the GPIO set high beforehand. But when I assign the pins using M950, some of the states change. For example, assume that all GPIO outputs are set high at 3.3V. So when I query the object model of those pins, they all say this:
{"key":"state.gpOut","flags":"","result":[{"pwm":1.00},{"pwm":1.00},{"pwm":1.00},{"pwm":1.00},{"pwm":1.00},{"pwm":1.00},{"pwm":1.00},{"pwm":1.00},{"pwm":1.00}]}
Which is what I expect.
Then I'll send down the following commands sequentially:
M950 P0 C"io0.out"
M950 P1 C"io1.out"
M950 P2 C"io2.out"
M950 P3 C"io3.out"
M950 P4 C"io4.out"
M950 P5 C"io5.out"
M950 P6 C"io6.out"
M950 P7 C"io7.out"
M950 P8 C"io8.out"For some unknown reason, pins 4, 5, and 7 get switched low to 0V during those assignments and I have no idea why they would switch when all I'm doing is assigning them and not setting them. Even when I query the object model again, I still see that all pins are said to be high even though pins 4, 5, and 7 are low.
What's going on? Why do only those 3 gpio pins get switched when I'm assigning pins? I'm not even setting them at all which is concerning since the board even thinks that they're all set high when they're physically not which puts it at an unknown state. Am I missing something?
-
seems to be related to the type of output https://duet3d.dozuki.com/Wiki/Duet_3_Mainboard_6HC_Hardware_Overview#Section_IO
-
Hi,
Would it not be simplest to configure them and then set them to a known state?
Does it really matter if the states might change DURING configuration?
Frederick
-
I expect after assigning M950 the pullups are activated and behave differently to your measuring method of the voltage.
-
So I'm using all 9 GPIO outputs to drive some valves and I have all the GPIO set high beforehand. But when I assign the pins using M950, some of the states change.
Maybe I'm missing something here, but don't you need to create the pins with M950 first, then set values with something like M42? In any case there seems to be a difference with the three pins that do support pwm outputs, but if you can set the values immediately after then not sure I see the issue. To have predictable behavior before firmware is in control add external pull up/down?
I expect after assigning M950 the pullups are activated and behave differently to your measuring method of the voltage.
Wouldn't activation of pull ups require a ^ in the pin name? So there shouldn't be any pull ups active as its missing. Adding one might help though, but i'd put my money on external pull up if this is an issue in a undefined state.
-
@stevenim I have found it:
https://duet3d.dozuki.com/Wiki/Connecting_a_Z_probe#Section_Software_setup_RepRapFirmware_Num_3
in.4,5,7 are inverted to support Z probe:
"On Duet 3 it is one of io4.out, io5.out or io7.out. If you use one of these pin names, you will not need to invert the output."
So don't have to invert output means normal state 0.@bearer I read in the docu that the io pins of Duet 3 have pullups alreay (27k), so they don't need the ^.
https://duet3d.dozuki.com/Wiki/Connecting_endstop_switches#Section_Duet_3_endstop_inputs
My thought was that maybe by the assignment of the pins the resistors were activated, but the reason was invert for z probe. -
@JoergS5 said in M950 GPIO Bug:
@bearer I read in the docu that the io pins of Duet 3 have pullups alreay (27k), so they don't need the ^.
https://duet3d.dozuki.com/Wiki/Connecting_endstop_switches#Section_Duet_3_endstop_inputs
My thought was that maybe by the assignment of the pins the resistors were activated, but the reason was invert for z probe.mixing inputs and outputs here? inputs have pullups yes, not the outputs. (well, buffered outputs have pulldowns leading up to the buffer, but the unbuffered io_n.out do not)
-
