iDMX and RGB Nodes - some nodes skip to end of fade

[heystew]

I am using the iDMX-1000 to control some RGB strings from John at http://response-box.com/rgb/. The iDMX is connected to the node controller which has 4 strings of 42 nodes each attached. This results in 168 nodes or 504 channels total. See the picture below for the physical connections. I've seen the thread indicating the DMX fades are not supported, and are treated as LOR intensity fades. This seems to be a different issue.

Problem:
when fading up/down some nodes seem to jump to the end of the fade command. i.e. fading from 0 to 100% most of the nodes will fade appropriately while some number (predicatable) will jump straight to 100%. This also happens on fade down. (video of behavior during show at

)

Troubleshooting:
- setup a test animation file with only one iDMX, one node controller and 4 strings with no other controllers connected or configured
- fade from 0 to 100% blue in 7.5 sec. then fade from 100 to 0% blue in 7.5sec
- Works perfectly with 128 nodes fading on/off
- begins to decay when adding the 129th and following nodes (there are 168 nodes total)
- failure mode is that at the start of a fade up, one or more nodes will go to full on. during a fade down, one or more nodes will go to full off.
- as more nodes get added more nodes seem to jump ahead to their either full on or full off state (does not seem to be a 1:1 correlation though)
- tried using both the Color Fade Tool and the Fade Up tool with the same results
- happens with both short and long fades
- with 129 nodes fading, the impact is on node 5 (channel 15 for blue)
- when switching to green with 129 nodes fading, the impact is on the same node, which is channel 14 for green
- taking a look at the XML in the .las file, the commands for node 128 and 129 are identical
- the problem seems to be based on the # of fading nodes, not the position of them. If I remove Node 1 from the fade, all is well. If I leave node 1 out and add in node 130, the problem is back.. and still on Node 5(channel 15)

other info:
- happens on both version 2.9.4 and 2.8.12
- happens with several different show pc's both fairly powerful machines. one with XP, one with Windows 7
- happens when configured on both Standard or Aux network
- happens when at all three network speed settings (low, medium, high)
- using USB485B isolated (and non-isolated in testing)
- I'm also communicating with John (the vendor) but it seems like it's an LOR or user error issue.



Please let me know of any thoughts to continue troubleshooting or other tests i can run. I've attached the sequence file with 129 nodes fading. This demonstrates the issue and it shows up on node 5 (channel 15)

Thanks!

Dave













Attached files bluetest.las

[-klb-]

The original iDMX firmware only supported 64 ichans. You must have the. Newer firmware that supports 128 ichans. Any LOR effects (anything other than on/off) require an available ichan to compute the frame by frame intensities to be set. Once you run out of ichans, you start getting on/off behavior.

[heystew]

so given this information i modified my test to use purple (fading up both R and B channels) to see if the problem would occur with lower numbers of channels. Yes it does, so it seems as if this is the problem.

Quite disappointing I must say. Is there any way around this or an upgrade coming? Now that i search on ichan on the forum i see that this is a known limitation with it unlikely that we'll get more than 128.

I'll have to see how i can modify the show as the hardware is pretty much set in stone.. i've got 7 iDMX's so i'm fairly committed.

Any other suggestions? as you can see from the video, it kind of cripples the show.

thanks,
Dave

[Steve Constantino]

I have been dealing with this problem sense the iDMX-1000 came out. I have five iDMX units that I use and it can be a little challenging to program nodes with only having 128 intelligent channels per unit.

There are some rumors that LOR will support Artnet or E1.31 ( I hope for Artnet) some time soon. I hope sooner than later. This will solve lots of problems.

Steve

[heystew]

given that it's difficult to tell exactly how many intelligent actions you may have occuring at any one time with large scale use of DMX channels like this. Is the 128 limit something that could be checked with the Verifier? It could flag any time that more than 128 intelligent commands are being conducted for a single iDMX unit.

Not sure how feasible, just one thought of how to help ease the pain.

[Ponddude]

I don't believe that the verifier will check that. However, because these are RGB channels, realize that they are 3 "regular" channels combined. In theory you are only going to get 42.6 (42) channels doing a fade at one time. I believe those strings are 42 nodes a piece and if they are all fading, you are not going to be able to do what you want to do. LOR really needs to address this by introducing some sort of Art-net controller.

[Steve Constantino]

Ponddude wrote:

LOR really needs to address this by introducing some sort of Art-net controller.

COPY THAT!!!


Steve

[heystew]

Ponddude wrote:

I don't believe that the verifier will check that. However, because these are RGB channels, realize that they are 3 "regular" channels combined. In theory you are only going to get 42.6 (42) channels doing a fade at one time. I believe those strings are 42 nodes a piece and if they are all fading, you are not going to be able to do what you want to do. LOR really needs to address this by introducing some sort of Art-net controller.

Correct, that's why I've tried to stay with just fading red, green, or blue independently rather than an RGB combination.. at least I get 75% of my nodes to fade... Unfortunately this kind of defeats the purpose of having RGB capability.

As far as the verifier, I was just speculating as to whether this might be a capability that could be added as an option that could be chosen by the user if they knew they may have this type of conflict.

Thanks