DMX with LM5p - errors

[tss68nl]

Hi,

I have been trying the DMX examples on this site, but no matter what I try, the examples giving me the following error in the error log:

User library DMX:80: cannot open port
stack traceback:
[C]: in function 'error'
User library DMX:80: in function 'reset'
User library DMX:66: in function 'init'


I have no clue how to solve this.

Also, I want to run almost 200 DMX channels on one DMX interface, and run a second on the other 485 interface. I believe that I found a resource about how you need to do this differently due to performance, but cannot find the resource describing what has to be altered? I think there was also an example with 3 DMX interfaces?

Thanks for your effort in advance!

[tss68nl]

Well I managed to get the error gone by using 'RS485-1' as the port name. However....still nothing happens.

If I put an alert in the resident script, it executes every second, but, if I put an alert in the 'run' procedure of the user.dmx library, nothing ever shows. So either the function never runs, or my changes inside the library are not picked up.

Yes, I do disable/enable the resident script after each save (which is tedious, but necessary). Any clue on how to debug this script when there are no functions able to report an alert back?

[admin]

First, make sure that you are using this updated DMX library:
https://gist.github.com/jsopenrb/f97f85f...c6766aae6a

Do not make any changes in the library, but change parameters in DMX.init (note that it must be DMX.init not DMX:init):

Code:

dmxhandler = DMX.init({
  port = '/dev/RS485-1',
  channels = 3,
  transition = 2,
  resolution = 10,
})

Since you have a lot of channels, you have to lower the resolution parameter to decrease CPU load.

For the second line, you have to add skey = 'dmx_line_2' parameter, otherwise both lines will use the same storage key thus the same channel values.

[tss68nl]

Since you have a lot of channels, you have to lower the resolution parameter to decrease CPU load.

Thanks, the DMX interface is now working properly. 

Regarding performance, I think I saw a discussion that using the storage for variables is not fast enough with a high number of channels. Do I get it correctly that I would need to use variables that are declared in the resident script? Those are like global vars, and can be read/written from the procedures in the user libraries?

And what would be the maximum of channels * resolution that you can send? Sending the full 512 channels with a resolution of 10, is that possible?

Also, does DMX allow you to send just the channels you need from an array? In the existing DMX system that I am programming against now, the drivers are put on the 10, 20, 30 marks... so driver 1 channel 1 = DMX 11, driver 18 channel 4 = DMX 184. Seeing they are mostly RGBW drivers and an occasional WW driver, 60% of the addresses is never used, and a waste to send over the line? Would I be able to send channels 1,2,3,4,11,12,21,22,23,24,31,32,33,34....etc, or does the whole system need a full reconfigure/reprogram? (No fun, reprogramming a full building with dmx hardware)

[admin]

Previously, each channel was stored in a separate storage variable, now the whole value array is stored. This is much faster, so you don't need to change anything. We haven't tested 512 channels, so you might have to lower the resolution if CPU load is too high.

In DMX bus Each frame consists of starting mark and a number of data bytes. Each byte position relative to the starting mark is the address, so you cannot skip empty addresses. It's better to have the bus addresses in sequence, but there's no big harm in having unused addresses.

[tss68nl]

Hello Edgar/admin,

I have rewritten the DMX library to my own needs and altered quite some functionality, but I am puzzled about something in the original DMX library you have written.

It stores the current values in storage (storage.exec), and each second, retrieves them from storage, populates an array with them, calculates the DMX updates and then forgets about them. But why are the current channel values in storage?

• You could just leave the values in the channels array am I right?
  
• Changing to a new target value could be done by the set function directly to the value array as well I think?
  
• I believe the array is lost anyway when the calling resident script is deactivated/activated, so the storage will only be useful to refill that array with the old current values? But you don't know how current they are?
  
• And if the storage is there to just fill the channels array in memory on a restart, then why not only call it on a restart?
  
• I thought about memory efficiency, but seeing the array is filled every second anyway the memory will be taken anyway.
  

Am I missing something here?

[admin]

Storage is used for sharing global data between scripts. Each script is a separate OS process, so they can't share data directly. Since final DMX channel values are placed in storage they are not lost between script restarts.

[tss68nl]

Thanks for your swift reply. Yeah, you cannot get any data to the dmxhandler from outside the resident script itself... that's cumbersome to say at least.

I am using the DMX library for firmware after 7-2016, but I see that the normal documented storage.set() and .get() have been replaced with some undocumented .exec('lset', , , ) and 'lrange' syntax? Also, using the storage viewer app, I can only see the keys of the (non-working) Alert-app from Erwin. I should see the stored DMX values am I right?

[admin]

Storage uses Redis server, storage.exec allows executing commands directly (https://redis.io/commands). Viewer app does not support all Redis types, that's why some keys are not shown.

[Erwin van der Zwart]

Hi,

Non working alert app? It's used on many locations without issues, what is not working according to you?

BR,

Erwin

[tss68nl]

Storage uses Redis server, storage.exec allows executing commands directly (https://redis.io/commands). Viewer app does not support all Redis types, that's why some keys are not shown.

Aha, that makes things much clearer. I see that with lset you can just have one element in an array written, instead of retrieving and writing the full array. I made my own version with get/set of the full array, and timed it around 12ms for reading and 15ms for writing. which makes a tight fit if you want to do this within the first frame of a DMX channel with resolution 40. (Yeah I know....20 will work just fine, but I want the software to be robust and be able to go to the highest freq).

I will try the lset way, but it's funny how the storage is nog showing up. It does with get/set. I am curious if the command will be much faster, because storing an empty key always times around 10ms, which seems to be the minimum for Redis. 10 and 12 ms is not so much of a difference.

For the current values I use the in-memory channels table, and I pick convenient times to store the array to storage in frames where I don't have much else to do.


@Erwin: Not sure, it gives me a screen that looks without CSS formatting. Just a bunch of checkboxes and empty dropdowns in a row. I will probably need to upgrade firmware version then reinstall the alert app. Will upgrade and fix when I have some time