Looking at the OPTOMUX PROTOCOL GUIDE, I need some info on the various field widths in the ASCII command examples.
I am seeing a variation in the length of positions, modifier, and info fields. Now for positions, it seems that the length could be determined by the number of digits required for the upper most set bit. The modifier and info field lengths when present seem to be command dependent.
Page 83 shows the message >11Z66L015842cr. Positions get 2 digits and info gets 2 digits per value.
Page 99 shows the message >FFJ000A4003Bcr. Positions gets 4 digits even though top 3 are 0, and info gets 3 digits due to I guess the 12 bit analog nature.
Page 101 shows the message >D0S0224FFF0C01F0ABcr. Positions gets 4 digits and 3 analog values get 3 digits each again I assume due to 12 bit nature.
As a verification, I want to create the exact messages in my code shown in the examples without wasting effort on things in the examples that are not a requirement, ie: I don’t really want to keep a positions field width spec by command if it is unnecessary.
So for the positions field, the number of hex digits seems to vary among example messages. Am I free to shorten the field to drop upper zeros? That is how do I know to do 66 instead of 0066 or 066, or A instead of 000A, 00A, or 0A? I am attempting to use the example messages to verify my packet output including checksum, but it is a concern if some messages expect positions to be four digits, and some to drop upper zeros.
The same is true about the data or modifier fields. It seems like analog output commands may want 3 digits for parsing, but other commands may want 2 digits, or even 1 digit.
Hi, Doug:
Some commands require positions and/or modifier and/or data parameters and other don’t. Unfortunately, other than the Positions field, the Modifier and Data fields depend on the command.
The Positions field contains from one to four ASCII-hex digits; leading zeros can be omitted (but they don’t have to be omitted).
The Modifier field is dependent on the command.
The Data field can contain from 1 to 64 characters, depending on the command.
Page 83 shows the message >11Z66L015842cr. Positions get 2 digits and info gets 2 digits per value.
Positions could be 0066 or 66. Data is specified by the command to be 2 characters.
Page 99 shows the message >FFJ000A4003Bcr. Positions gets 4 digits even though top 3 are 0, and info gets 3 digits due to I guess the 12 bit analog nature.
Positions could have been A instead of 000A. Data is 12 bits (3 ASCII characters) per analog value because Optomux analog modules are 12-bit.
Page 101 shows the message >D0S0224FFF0C01F0ABcr. Positions gets 4 digits and 3 analog values get 3 digits each again I assume due to 12 bit nature.
Positions could have been 224, rather than 0224. Data is 12 bits (3 ASCII characters) per analog value.
We hope this info helps. Let us know if you have additional questions.
Thanks for the quick response. Still working through the optomux examples. Some things that I noticed in the manual:
Page 133, in the message “>AAR007074AA00E4cr” I compute the checksum to be E8. Of course I could have a bug, but I have done more than 50% of the examples and had no other mismatches.
Page 144, the Turn Off Existing Waveforms does not have an example. The packet claims to be the same as Set Output Waveform excepting it does not require a data field. But Set Output Waveform has two modifier fields, rate and type. So it is a bit unclear if I send 00 or 0 in the modifier field. Below I repeat the examples for Set Output Waveform but drop the info field and set modifier field to send a single 0 rate nibble.
Page 133: You are right—the checksum isE8. Thanks for the correction; I will update the manual tout suite.
Page 144: Here’s the verbatim answer from our Engineering Dept:
For the “Turn Off Existing Waveforms”, a single zero for the waveform type should be good enough. We would have to have four nibbles in the positions array:
.> 00R10130 CHKSUM A7 Though I would STILL put the second zero in there also >00R101300 CHKSUM D7
.> AAR700600 CHKSUM AF
We hope this info helps, and feel free to let us know if you have further questions or corrections.
The engineering response is a bit confusing. The statement, “We would have to have four nibbles in the positions array” seems to violate the ability to drop leading zeros and makes this command uniquely formatted in that respect. It seems I should be able at a minimum drop the info section and change the modifiers to 00 and recompute the checksum.
So > AA R 0070 74 AA 00 should become > AA R 0070 00. But I should also be able to drop the leading zeros from positions, making it: > AA R 70 00.
If you were planning to add these examples to page 144, I’d revisit them.
Hi, @dougm
I’m so sorry I didn’t see your response until just now.
I got a clarification about “dropping the leading zeros”:
When the positions field immediately precedes the end of the Optomux message (that is, there are no other fields between the positions field and the checksum), then leading zeros in the positions field can be omitted.
So what I implied earlier about “leading zeros can be omitted” wasn’t 100% accurate.
I finally have a rack of working hardware. Admittedly dated, as it is B3000ish. I have been using a terminal to investigate optomux commands further. One thing to note is that optomux will ack a command even if it is constructed incorrectly.
00B?? ; send a reset
A ; optomux likes it
00j?? ; request configuration
A0000C0 ; manual says "After sending a Reset command to a B3000 brain, you must send a Power-Up Clear command.
; Otherwise, the brain responds with an error.
; apparently not as I am using a B3000
00A?? ; send a power up clear ack
A ; optomux likes it
00j?? ; ask for configuration
A0000C0 ; all inputs
00G1?? ; set first channel to be output
A ; optomux likes it
00j?? ; ask for config now
A0001C1 ; optomux made first channel an output. Note here that I can freely drop leading 0’s in positions
00n1?? ; set timer res to 10ms
A ; opto likes it
00i1320064?? ; tell first channel to generate 100 1 second pulses
A ; optomux likes it but does nothing
00i01320064?? ; tell first channel to generate 100 1 second pulses
A ; optomux likes it but does nothing
00i001320064?? ; tell first channel to generate 100 1 second pulses
A ; optomux likes it and light now blinks as expected
; so the generate n pulses command does not properly support dropping positions leading zeros but it works if only 3 digits are provided
Thanks for the additional info, Doug—We really appreciate your feedback.
I’ll ask our Product Support Group to help me investigate the responses you got so I can properly update the Optomux Protocol Guide.
Best wishes,
Gray
I am a bit confused by the behaviour of the Set Time Delay command. The manual says, “Sets specified output points to be used in a pulsed or delayed mode.” For both the Write Digital Outputs and Activate Digital Outputs It says “Time delays, if set, are implemented when this command is executed”. The problem seems to be that the pulsed or delayed mode configuration does not persist for more than one output execution.
What I expect is for the command to configure the specified output to pulse with each activation request once it is set up. In the case of the Set Time Delay H modifier, it would be similar to the Start On Pulse command.
The communications below indicates that the Activate Digital Outputs or Write Digital Outputs command pulses once and then clears the delay, requiring the Set Time Delay be resent each time.
00n01?? ; 10ms timer
A
00Z0001H64?? ; set up a 1 second pulse
A
00J0001?? ; generate a pulse. It works OK.
A
00M?? ; output is off after a 1 second delay so this comes back clear
A0000C0
00J0001?? ; generate another pulse. Nope, output turns on and stays on.
A
00M?? ; read back that it is in fact still on
A0001C1
00L0001?? ; turn it off
A
00M?? ; verify it turned off
A0000C0
