USBDMX / serial object / send more than 256 values
Hi everyone,
I am running into an issue when trying to control DMX lighting from max using an ENTTEC USBDMX Pro interface. I am unable to send out more than 254 dmx channels, (which ads up to 256 including start and stop bit). If I try to send more than 254 channels, it seems that no data is being sent out the serial port at all (though I am not 100% sure of this, but the lights seem to be unresponsive at least). It does seem there is output, but it is unpredictable - last try only channels 1-45 were responding, the rest remained off. This unexpected behavior only occurs when crossing 254 channels.
I am using the attached patch below to send my data from MAX 8 to the USBDMX interface.
I know the zl object has a default maximum size of 256, which was my first suspect. So I made sure that my zl objects are set to @zlmaxsize 512 (one DMX universe). Hence I am sure that the data going into the serial object is the correct size, which I also verified using zl.len.
I ruled out hardware issues as well by using ENTTEC's EMU software to control the system instead of MAX, which works flawlessly.
The only thing I can think of is that the serial object in MAX has a limitation here that I am not aware of. From looking through the documentation however I am not able to determine if that is the case, but that is probably because of my own lack of knowledge.
Anyone who can help me figure out the issue and perhaps find a solution?
Maybe you could try to bang list with the values at frame rate interval,
instead of directly sending it to serial object.
metro 25 is 40 frames which should be supported
Maybe you could try to bang list with the values at frame rate interval,
instead of directly sending it to serial object.
metro 25 is 40 frames which should be supported
The input of the shared patch is a list with 300 char values, at 30fps (metro 33), though the framerate may drop a bit occasionally depending on what all I'm doing on my screen, but its pretty stable at 30fps if I leave it running without interfering.
I don't see how framerate would result in this problem specifically when my list exeeds 254 values?
Have you seen this thread?
https://cycling74.com/forums/second-universe-on-dmxusbpro-mk2-let's-get-it-once-and-for-all-!/
Maybe it's useful
Sorry but I cant paste the correct link,
anyway the thread titel is:
second-universe-on-dmxusbpro-mk2-let's-get-it-once-and-for-all-!/
Have you seen this thread?
https://cycling74.com/forums/second-universe-on-dmxusbpro-mk2-let's-get-it-once-and-for-all-!/
Maybe it's usefuluseful
Hadn't seen it, but its addressing a different issue. A dmx universe is 512 channels, my problem starts at 254 channels, so it isn't related to the size of a dmx universe.
I thought maybe its related to the buffer size of the serial object. Its set to 2048 in the patch I used. 256 times 8bit dmx values comes to 2048 bits. But setting it to 4096 (512*8) didn't resolve the issue. And the documentation is saying maximum buffer size is 1024 , so that doesn't clear things up either...
And I'm honestly not sure what the buffer size means in the context of serial communication either.
I think your mistake is DMX list length which is 2 bytes LSB MSB
126 6 $1 0 won't do .
calc is number of channels +1 LSB MSB
That works ok up to 254 channels = 255 0 LSB MSB if you set MSB to fixed zero .
255 channels would be 0 1 LSB MSB
256 channels 1 1 etc
P.S. it is actually not your mistake, but of all this posters which copy -paste
stuff, without really explaining the facts or even understanding the patches
themself.
Aha thanks, that clarifies a lot! Hadn't quite grasped the LSB MSB part before, but now I understand. Will take a shot at it this afternoon 🙂
[edit] tried it, and it works now! :)
Also explains why only channels 1-45 were working when feeding 300 channels. The LSB value simply wraps after 255, so 300 0 LSB MSB equates to 45 0).