Duet 3HC support of M670 command?
-
Hi, I am trying to configure the IO port bit mapping on the 3HC expansion board but for example when I try to run the command: M670 C"1.out0" , I get "M670: Remote ports not yet supported by this command". Is there any way to make M670 work with the expansion GPIO pins?
Kind regards,
R.I -
I didn't know anyone was using the M670 command! Can you tell me what you are using it for?
The most straightforward way we could make M670 work with ports on the expansion board would be to change the M670 command to take GpOut port numbers instead of taking port names directly.
-
I was thinking that the M670 command can be used as a sort of real time (buffered) communication method. From running some experiments with an alternating combination of M106 and G1 commands, the M106 command is run as soon as possible so I can't have:
M106 P1 S255
G1 X100
M106 P1 S0
M106 P1 S255
G1 X100
M106 P1 S0
etcIn that specific case, the M106 turns on the fans on an off at the beginning of the movement rather than respecting the run order.
This is where M670 comes in. I think I can use it to make an 8bit parallel buffered communication method if I use 8 gpio pins so every time I do movement with G1 I can send a message to an outside micro-controller. I was thinking of using this do do a simple multiple colour extruder.
-
@Robert-I said in Duet 3HC support of M670 command?:
I was thinking that the M670 command can be used as a sort of real time (buffered) communication method. From running some experiments with an alternating combination of M106 and G1 commands, the M106 command is run as soon as possible so I can't have:
M106 P1 S255
G1 X100
M106 P1 S0
M106 P1 S255
G1 X100
M106 P1 S0If you run those commands from a GCode job file then the M106 commands will be synced to the G1 commands.
-
When I ran my little experiment I just wrote the gcode by hand and uploaded the file to PronterFace and ran it. Either way, I still need to use M670 as it gives me more bandwidth. I managed to make enough space on the 6HC board so I don't need to use M670 with the expansion anymore. I discovered a new problem though, if I understand the bitmap correctly, if I have a G1 X... P11111111, then all the pins should be set to high which doesn't seem to be the case. I am currently using the following configuration
M670 C"OUT2+OUT3+OUT4+OUT5+OUT6+OUT7+OUT8+OUT9" but not all the pins are turned on. When I go and turn them on one by one (i.e G1 X... P00000001) they work fine though. -
@Robert-I Nvm I figured it out. I am posting it here as other people mind find it useful as I don't believe this is mentioned in the documentation. After you set your output bits with M670, for example:
M670 c"out2+out3+out4+out5+out6+Out7+out8+out9+!io8.out"
To turn on the bits, the P parameter for G1 takes a decimal coefficient and then it is converted to bits by the firmware so for example, to turn all the pins I declared on, since they are 9, I will have to write: G1 X... P511 which corresponds to 111111111.
-
I should also mention that there is a finite number of pins you can use with M670 as there is a hard limit on the number of characters in the C parameter of M670. I managed to squeeze in 10 pins like this
M670 C"OUT0+OUT1+OUT2+OUT3+OUT4+OUT5+OUT6+OUT7+OUT8+OUT9" but you don't have any space left for a heater so its more reasonable to get 9 bits with this as it leaves you with two heater outputs:
M670 C"OUT2+OUT3+OUT4+OUT5+OUT6+OUT7+OUT8+OUT9+!IO1.out" -
I will probably change M670 in RRF 3.2 to take GpOut port numbers (created using M950 Pnn) instead of taking port names directly. That should allow ports on expansion boards to be used, as well as getting around the 50 character limit of the M670 C parameter.
-
That's great! Thank you for the help and quick replies!
-
If/when we do a 3.1.2 release, I will increase the 50-character limit on the M670 C parameter, as a temporary workaround.