Hi there,
Just checking if anyone else is experiencing this;
During the last season that I worked on, I used LXConsole plus an eDMX4 RDM device via my pre-retina MacBook Pro native Ethernet out plus a compliant PowerOverEthernet adapter. In the past, I have used a DMX USB PRO Mk2 device.
I notice it mainly in obvious, bright states with quickly switching lanterns, but after a two-week-season, I am sure to have seen irregular but persistant (2-4 per evening) tiny micro power-outages (like a tiny flicker off). Like I said, in the past, I understood that this might have to do with using a USB device (see also here), but have since changed over to ArtNet.
Claude, I believe you mentioned that in absence of new packets, an artnet receiver usually just keeps the last value. Is there any chance that this issue is software based, i.e. are there any circumstances (without showing error messages), that LXConsole might send brief, random "black-out" packages? I am trying to get my hands on some sort of DMX monitoring software, then I could hook the artnet device's DMX-outputs to a DMX-input to write a continuous log, but in the meantime, if you have any ideas what this might be related to?
brief flicker
-
freadZdead
- Posts: 211
- Joined: Sat Jun 01, 2013 8:23 am
- Location: Adelaide, Australia
brief flicker
Cheers,
Freddy
Freddy
You can test to see if your interface holds output levels when not receiving packets by switching off LXConsole's ethernet interface. But, this is highly unlikely because when idle (no cues or effects running or user initiated changes) LXConsole sends a "keep alive" dmx over ethernet packet once per second, not continuously.
v3.5 has a number of improvements that address the possibility that lights might jump or appear to flicker when multiple changes are occurring simultaneously.
This could be particularly acute with OS X 10.9 when LXConsole was not the foreground application. The 10.9 operating system includes a new feature called "App Nap" that slows processor cycles devoted to background applications when it determines that they need a "nap". v3.5 tells the operating system it is doing something important and shouldn't be put to sleep while it is running cues or effects or when OSC input is enabled. (MIDI is integrated in the operating system and it seems to know that MIDI events should override app nap.)
There were also fixes for several issues that became apparent when the application was being asked to do multiple things simultaneously. These may have resulted in a jump in levels. Most of these, like the app nap problem, were the result of something delaying an update of a running cue. When the processor got back to the running cue, it updated the levels to account for the elapsed time and the lights appeared to "jump" to their new levels.
The things fixed were internal. But, the possibility exists that under heavy system load, a similar thing could occur where LXConsole would simply not be able to keep up. An example might be where a number of applications were open and RAM memory was low enough to require frequent swaps of virtual memory pages to the hard disk. Another might be anti-virus kicking in to do a scan in the background. As OS X becomes more of a consumer operating system, there are more processes tacked on such as iCloud synchronization. While these features are designed not to appear to slow down the user interface, the background processing can interrupt real time software such as LXConsole. While this may never be enough to notice when you are simply running a normal one cue at a time show, it may be enough to cause delays when you are running multiple effects on top of a cue and adjusting levels using MIDI or OSC as well.
If you can find a reproducible flicker, we can investigate. Otherwise, there are too many variables to even begin to speculate. However, important things to note are if LXConsole is the front application and what other processes are running at the same time. The DMX interface is probably the least likely to be the cause of the problem, however.
v3.5 has a number of improvements that address the possibility that lights might jump or appear to flicker when multiple changes are occurring simultaneously.
This could be particularly acute with OS X 10.9 when LXConsole was not the foreground application. The 10.9 operating system includes a new feature called "App Nap" that slows processor cycles devoted to background applications when it determines that they need a "nap". v3.5 tells the operating system it is doing something important and shouldn't be put to sleep while it is running cues or effects or when OSC input is enabled. (MIDI is integrated in the operating system and it seems to know that MIDI events should override app nap.)
There were also fixes for several issues that became apparent when the application was being asked to do multiple things simultaneously. These may have resulted in a jump in levels. Most of these, like the app nap problem, were the result of something delaying an update of a running cue. When the processor got back to the running cue, it updated the levels to account for the elapsed time and the lights appeared to "jump" to their new levels.
The things fixed were internal. But, the possibility exists that under heavy system load, a similar thing could occur where LXConsole would simply not be able to keep up. An example might be where a number of applications were open and RAM memory was low enough to require frequent swaps of virtual memory pages to the hard disk. Another might be anti-virus kicking in to do a scan in the background. As OS X becomes more of a consumer operating system, there are more processes tacked on such as iCloud synchronization. While these features are designed not to appear to slow down the user interface, the background processing can interrupt real time software such as LXConsole. While this may never be enough to notice when you are simply running a normal one cue at a time show, it may be enough to cause delays when you are running multiple effects on top of a cue and adjusting levels using MIDI or OSC as well.
If you can find a reproducible flicker, we can investigate. Otherwise, there are too many variables to even begin to speculate. However, important things to note are if LXConsole is the front application and what other processes are running at the same time. The DMX interface is probably the least likely to be the cause of the problem, however.
-
freadZdead
- Posts: 211
- Joined: Sat Jun 01, 2013 8:23 am
- Location: Adelaide, Australia
Hi Claude,
Thanks for the detailed explanations, here a few clarifications about my situation when I noticed these things:
A) QLab 2 was foreground, LXConsole was background, on a dedicated 10.8.5 system, not Mavericks.
B) I would consider the load generated by QLab as light - no Projections/Movies running, and about 8 Audio tracks (wave files of about 3-4 minutes each) loaded into memory, though not playing simultaneously - basically a pre-show playlist.
C) LXConsole was not running any cues or effects at that stage it was sitting in LX Cue 1 (the pre-show state), with a handful of channels up (including the QIs that are the houselights).
D) I was using Version 3.4.6 (7608A)
I hope despite the fact that this show is over, that I will have a chance maybe this weekend to try and hook up two computers up to each other, to see if I can reproduce and log the flicker. I will also try and investigate more closely what happens if I switch off the LXConsole's ArtNet sender. I will try to reproduce the flicker first, and then try to update to 3.5 and see if the errors persist.
In the meantime, has anyone else similar observations to report?
Once again, thanks already for your analysis!
Thanks for the detailed explanations, here a few clarifications about my situation when I noticed these things:
A) QLab 2 was foreground, LXConsole was background, on a dedicated 10.8.5 system, not Mavericks.
B) I would consider the load generated by QLab as light - no Projections/Movies running, and about 8 Audio tracks (wave files of about 3-4 minutes each) loaded into memory, though not playing simultaneously - basically a pre-show playlist.
C) LXConsole was not running any cues or effects at that stage it was sitting in LX Cue 1 (the pre-show state), with a handful of channels up (including the QIs that are the houselights).
D) I was using Version 3.4.6 (7608A)
I hope despite the fact that this show is over, that I will have a chance maybe this weekend to try and hook up two computers up to each other, to see if I can reproduce and log the flicker. I will also try and investigate more closely what happens if I switch off the LXConsole's ArtNet sender. I will try to reproduce the flicker first, and then try to update to 3.5 and see if the errors persist.
In the meantime, has anyone else similar observations to report?
Once again, thanks already for your analysis!
Cheers,
Freddy
Freddy
It is easy to jump to the most complex cause for a problem... Just a thought, have you tried switching out dimmer modules? I don't know what kind of dimmers you have. But I have observed a failure mode in ETC Sensor dimmers where the exact kind of dropout you describe occurred, Its easy to confirm because the problem follows if you switch modules. Its also not very hard to replace the power cube and repair the module.
The fact that LXConsole is just sitting there and there's a flicker tends to make me think that it is probably not software related. You could confirm this by loading the cue and then disabling ethernet and see if the flicker still occurs.
The fact that LXConsole is just sitting there and there's a flicker tends to make me think that it is probably not software related. You could confirm this by loading the cue and then disabling ethernet and see if the flicker still occurs.
-
freadZdead
- Posts: 211
- Joined: Sat Jun 01, 2013 8:23 am
- Location: Adelaide, Australia
Hi Claude,
True. In this instance, they are using JANDS HP12s, and I will check if they have noticed this behavior with their inhouse lighting desk (an ETC ION). The reason why I thought of it being possibly software related was because it happened on different systems/cities, and with different DMX devices... The last I wanted to do is blame a great software for this
.
I'll investigate further and will report back. Thanks again for the further thoughts on the matter!
True. In this instance, they are using JANDS HP12s, and I will check if they have noticed this behavior with their inhouse lighting desk (an ETC ION). The reason why I thought of it being possibly software related was because it happened on different systems/cities, and with different DMX devices... The last I wanted to do is blame a great software for this
.I'll investigate further and will report back. Thanks again for the further thoughts on the matter!
Cheers,
Freddy
Freddy
You can always e-mail your file and tell me where to look and I'll see if I can see something. I have an eDMX 2 TX that I could test with.
It would seem to rule out dimmers if it happens in more than one setup. That was just a thought...
The DMX King interface supports both Art-Net and sACN. If you are trying things, you might try both to see if one makes a difference over the other.
It would seem to rule out dimmers if it happens in more than one setup. That was just a thought...
The DMX King interface supports both Art-Net and sACN. If you are trying things, you might try both to see if one makes a difference over the other.
-
freadZdead
- Posts: 211
- Joined: Sat Jun 01, 2013 8:23 am
- Location: Adelaide, Australia
I've had your file running for over an hour and 10,000+ Art-Net Packets and there's been no change or flicker that I've logged. I can do some more logging looking also at the DMX output of the DMXKing interface after the holiday weekend. But preliminary tests for 10-15min also showed no changes logged either.
I also created a dummy sub master using unpatched channels and ran it up and down through MIDI using QLab and the output remained constant. The DMX packets showed no changes.
I also created a dummy sub master using unpatched channels and ran it up and down through MIDI using QLab and the output remained constant. The DMX packets showed no changes.
-
freadZdead
- Posts: 211
- Joined: Sat Jun 01, 2013 8:23 am
- Location: Adelaide, Australia
-
freadZdead
- Posts: 211
- Joined: Sat Jun 01, 2013 8:23 am
- Location: Adelaide, Australia
Just thought I'd double the "All Clear" - I just ran the show from the same show computer, with the same eDMX 4 RDM setup, and recorded 4 hrs of the cue output of cue 1, with only the one DMX Frame showing, so I guess it must have been flaky power or dimmers indeed! Glad to have checked it with your help.
Cheers,
Freddy
Freddy
I'm using DMXWorkshop and sACNView, both running on Windows 7 as well as a tool I wrote to monitor packets running on OS X.
I wanted to make as sure as possible that it was not a software issue before going further into more likely causes. Beyond a failing dimmer, the most likely cause of a DMX flicker is probably in the cabling. This can be particularly hard to figure out because, sometimes it will be perfect and then randomly cause issues.
That being said, there are some basic things that are common mistakes. First, DMX should be run over 120 ohm DMX cable, not microphone cable. Some manufacturers have made this problem worse by using 3pin rather than 5pin connectors. This makes it very tempting to just use a mic cable instead of a proper DMX cable. Second, any kind of Y connection rather than using an active DMX splitter introduces the probability of reflections of the DMX signal which results in all kinds of ghost problems. Third, there are termination and connection issues that must be handled properly. There's a pretty good summary of DMX mistakes at:
http://www.lsclighting.com/help-centre/ ... -sometimes
I wanted to make as sure as possible that it was not a software issue before going further into more likely causes. Beyond a failing dimmer, the most likely cause of a DMX flicker is probably in the cabling. This can be particularly hard to figure out because, sometimes it will be perfect and then randomly cause issues.
That being said, there are some basic things that are common mistakes. First, DMX should be run over 120 ohm DMX cable, not microphone cable. Some manufacturers have made this problem worse by using 3pin rather than 5pin connectors. This makes it very tempting to just use a mic cable instead of a proper DMX cable. Second, any kind of Y connection rather than using an active DMX splitter introduces the probability of reflections of the DMX signal which results in all kinds of ghost problems. Third, there are termination and connection issues that must be handled properly. There's a pretty good summary of DMX mistakes at:
http://www.lsclighting.com/help-centre/ ... -sometimes