Sending commands to [serial] like a Terminal emulator would
Greetings wizards,
I need some help figuring out how to format commands to the Durand 4201-B DMX controller:
The controller supports sending commands directly from Hyperterminal or Zterm, and as an example, the command to Write values to the DMX channels is like this:
W0 # # # # # [CR]
W is the command, 0 is the DMX Start Code, then X number of channels as 0-255 values, then a carriage return. Note that there's no space between the W and the 0, but a space after that and between each number (don't think it matters whether there's a space before the CR). It's also possible that no 0 is needed right after the W, the docs on the device are good but that specific point is a little vague... so seeing it formatted both ways would be helpful. Tried many combinations of itoa, spell, atoi, etc. [serial] always complains unless it's a number, so no "W" as such can be sent, it seems.
What I need to know are a couple things:
1: How are the values sent from a Terminal if you typed that example code, like the 0-255 values? How about the spaces--as 32, and CR as 13? I don't have the device here to test it with a Terminal program.
2: Does [serial] take incoming numbers and convert them to ASCII to send them? Wondering how the device would know that the CR is just that and not a data value of 13. There's no set list length before the Write data line is sent, so there's got to be some inherent difference between how the channel values are sent versus the CR to finish the command.
It's been pretty confusing, have tried a lot of things, but nothing's happening yet. The device does recognize that there's a connection to [serial], it seems to just be the formatting issue. It would be great to just use the ENTTEC box with Olaf Matthes' [dmxusbpro] object, that was so easy to set up, but that's out of my hands in this case.
If anyone has any experience with sending similar commands and the way they interact with [serial], or some info on how [serial] or a Terminal emulator sends its data, I might be able to figure this out... that would be really really great. hopefully it's something simple I just missed.....
Thanks!
CJ
In the past with serially controlled devices, I've just sent lists of bytes : "87 48 32 50 53 53 32 50 53 53 32 50 53 53 13" for "W0 255 255 255 [cr]"
Is that not working?
Scott Fitzgerald wrote on Tue, 12 May 2009 07:03In the past with serially controlled devices, I've just sent lists of bytes : "87 48 32 50 53 53 32 50 53 53 32 50 53 53 13" for "W0 255 255 255 [cr]"
Will try it out. I guess I thought it was strange to have the decimal places represented as bytes, but if one needs to have special characters like spaces and CR then it makes sense, you'd have the whole range of characters plus the int/hex possibilities. The device is expecting hex so I'm assuming that for 255:
255 = FF = 70 70 or
78 = 4E = 52 69
it makes a lot of sense to me now, since there are the special codes like 32/space which will let the device know that a data value has finished, then it can create the correct value out of the values it just got. sprintf %X will be my friend here. it certainly was confusing at first.
thank you...that really helped my brain...will see if it works!
...Funny, I just got my old Durand 4201a to listen to Max a couple of days ago.
Check out this patch. It lets you set the first 18 DMX channels with the durand "W" command. The dialog box lets you send any command to the 4201.
This patch uses the Lhex external which you can find at maxobjects.com
Thanks guys, this was really helpful. Things are happening and I understand it now. The dialog is a nice feature, thanks for that too.
In case anyone is interested in this kind of serial communication from Max, here's a summation.
For turning an integer list into the right values for [serial], each value with a space separator:
-- convert each integer (0-255) value into a one or two-digit hex [sprintf %X]
-- [spell] the hex number as a byte (0-9 ==> 48-57, A-F ==> 65-70)
-- send the resulting one or two bytes out the [serial] ... (the receiving device may need a leading byte if it's only one)
-- send a space (32) ... does not need [spell]
.
.
.
-- possibly send an end code like CR (13) ... does not need [spell]
-- there may be a start code too...in the case of the Durand and probably other devices, these might be single capital letters before the numerical command or value list. Just send the raw byte for it, so "A" is 65, "W" is 87, etc.