SynchronizedOutputs - rmu75/linuxcnc-wiki GitHub Wiki

date: '2006-11-16T14:48:57' title: SynchronizedOutputs

User Story

A user wishes to control laser intensity, potentially setting a different value for each move. No existing approach seems to be satisfactory. A pause in motion is unacceptable. An analog output value is required.

Should support

  • Digital and Analog outputs
    • At least 4 of each, compile-time option
    • Each corresponding to a HAL pin
  • Occur synchronized with motion, at the beginning of the corresponding motion
  • Do not prevent blending or introduce pauses
  • Can change more than one output per motion
  • M62..M65 will silently be mapped onto these commands
  • The actual M-codes used need not be M200/M201

rs274ngc syntax

 M200 P- Q- (Set digital output P to value Q; P must be an integer from zero to the number of outputs, and Q must be 0 or 1)
 M201 P- Q- (Set analog output P to value Q; P must be an integer from zero to the number of outputs)

As long as these words are used with a motion that does not take P- or Q- (canned cycles), they may be placed on the same line: G1 X1 M200 P1 Q0

Alternate syntax

Parameters could be used instead of M-words #[2000+#x]=1 (Set digital output #x to TRUE) #[2100+#x]=1.25 (Set analog output #x to 1.25)

  • The actual variable numbers used need not be in this range Advantages:

  • Clear way to set more than one value at a time, does not interfere with other commands using P- or Q-

  • If inputs become possible, it can use the same syntax (each input is a HAL pin accessed through a rs274ngc parameter) Disadvantages:

  • Currently, the canon interface doesn't make any calls for "parameter set to value" or "fetch value of parameter"

  • Showing the new output value at the beginning of the move seems to violate the rs274ngc "order of operations"

implementation sketch

the state of each output is maintained in userspace, and included in each trajectory message sent to the motion controller. when a new motion begins, the motion controller copies each value to the corresponding HAL pin. Special handling may be necessary for an output change before a dwell or pause (G4, M0, etc).

Other items such as spindle speed, mist/flood coolant should use the same method.

other considerations

what happens in the case of error or abort? what about initial values?

should an integer (u32 or s32) type be supported? (Because of the converter components, I don't see a need to support s8/u8, but u32/s32 can express values not exactly expressible in HAL floats which have only 24 bits of mantissa)

related problems

digital and analog inputs from HAL to g-code (where they can be acted on with O-words, etc) are a related problem, but probably do not share any implementation

target version

emc2.2

sf.net task

not yet entered as an sf.net task