DMX with LM5p - errors - Printable Version +- Logic Machine Forum (https://forum.logicmachine.net) +-- Forum: LogicMachine eco-system (https://forum.logicmachine.net/forumdisplay.php?fid=1) +--- Forum: Scripting (https://forum.logicmachine.net/forumdisplay.php?fid=8) +--- Thread: DMX with LM5p - errors (/showthread.php?tid=872) |
DMX with LM5p - errors - tss68nl - 27.06.2017 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! RE: DMX with LM5p - errors - tss68nl - 27.06.2017 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? RE: DMX with LM5p - errors - admin - 28.06.2017 First, make sure that you are using this updated DMX library: https://gist.github.com/jsopenrb/f97f85f9d010c70cd61856c6766aae6a 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({ 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. RE: DMX with LM5p - errors - tss68nl - 03.07.2017 (28.06.2017, 06:20)admin Wrote: 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) RE: DMX with LM5p - errors - admin - 03.07.2017 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. RE: DMX with LM5p - errors - tss68nl - 19.08.2017 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?
RE: DMX with LM5p - errors - admin - 19.08.2017 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. RE: DMX with LM5p - errors - tss68nl - 19.08.2017 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? RE: DMX with LM5p - errors - admin - 21.08.2017 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. RE: DMX with LM5p - errors - Erwin van der Zwart - 21.08.2017 Hi, Non working alert app? It's used on many locations without issues, what is not working according to you? BR, Erwin RE: DMX with LM5p - errors - tss68nl - 21.08.2017 (21.08.2017, 08:11)admin Wrote: 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 |