Jean Iwanowski

Thank you for your precious help, you will be sorely missed! You set the bar pretty high, whoever comes next is going to have some really big shoes to fill! Best wishes for the future!

I will try if I can get my hands on such a device. I'll keep you posted if it happens. Thanks for the support, great as always !

I tried a different cable, and a different DMX termination, same behaviour. This is really strange. I just sent you the photo. Thanks for your help!

Hi Edward, Thanks a lot for the quick feedback. I'll inform the reseller of the problem with both the ClayPaky and the ETC fixtures that seemingly announce themselves incorrectly. What bothers me here is that I just linked the FLX and the fixture with a short DMX cable and terminated the line directly after the device. I do not see what could go wrong there. The cable could be damaged, or the cable/termination might have the wrong impedance, but they should not since they were sold as DMX compliant parts, and even then I am not sure it could have such an impact. In your experience, is such a cable problem probable? Otherwise either the fixture or the desk has a problem.

Thanks for this information. I attached additional information that might help prove that the explanation is correct : faulty_minib.heic :how the fixture schedule looks after RDM detection of the Mini-B faulty_minib. But as soon as I exit setup, another problem appears (see rdm_error.heic). I do not see how it can be related to the incorrectly announced fixture. Or does RDM communicate based on a device type, so the FLX tries to speak with an Axcor Spot 300 and the fixture does not answer since it actually is a Mini-B Spot? Thanks, I thought delta meant that only changes would be transmitted, which was a bit too error prone for my taste. But as long as frames still are periodically transmitted this is something worth a try. Nice trick. I will give it a try. Sad to see such bad implementations of a standard. It is true that I mostly see it happen on very low-cost fixtures where software engineering cannot be stellar, maybe I am to blame for buying such devices However the problem also happened from time to time on more high-end devices (ETC S4 LED Lustr Series 2). I am not sure the root cause can be the same for these... I just tested the fixture file provided by ETC. It seems to work when adding the fixture manually (the fixture is not recognized correctly either by RDM, see file faulty_ministar.heic), although it is not very user friendly (no gobo images on the FLX screen, no description of parameter values on encoder wheels...). Is it something you add in the library to make work with fixtures easier? If so, do you know if the Ministar will be added to the library soon? faulty_minib.heic rdm_error.heic faulty-minib.zos faulty_ministar.heic

Hi, There seems to be a problem when adding a Mini-B spot through RigSync : the device is recognized as Mini-B (name field in the Fixture Schedule screen) but the profile appears in red and is named something like "Axcor 300" (sorry, I do not have my FLX in front of me at the time of writing this message). The fixture then does not work at all. I tested this without any other device on the DMX line. When adding the fixture manually (RigSync disabled), everything works as expected. I also have a ETC ministar fixture that does not seem to exist in the library. Any plan to add it soon? If it helps, my reseller asked ETC for a fixture profile. You'll find it attached to this message (I have not tested it yet...) Unrelated question : I frequently have problems on my DMX network with fixtures that blink etc. I never could identify the source of the problem, but I suspect my low-end DMX-RDM splitters might have something to do with it. Anyways, my reseller advised me to lower the frequency on the DMX bus, which he said might help. Is this possible with the FLX? I could not find such a setting. Regards, JeanETC_HES_Ministar_customEB.zfix

Hi Edward, Sadly no debug file or error message shown upon rebooting. Is there no log anywhere that can be extracted from the console to help understanding the issue? I invested some time into further investigating the problem. What I can say is that the thing is 100% reproducible with my desk. Here are the steps : Click on Reset Desk, it works Enable RigSync Let RigSync discover some devices Click on Reset Desk again -> grey screen and unresponsive console -> reboot required (note : the Reset Desk is not done when the crash occurs as fixtures still are patched after the reboot) Repeat the previous steps -> the problem happens again. The attached video shows the desk's screen when the problem happens (sorry for the incorrect orientation). I only have two types of fixtures on my rig : 18x ETC SourceFour LED Series2 Lustr and 6x ETC ColorSourcePar. Something else is odd : RigSync cannot find the proper profile in the library for my fixtures : they all appear in red and in the Non-library fixtures category in the fixture list (see attached file img1). But when I try and reassign them to the correct profile in the library, the console seems to know what to choose as it only shows me the correct profile as alternative (see img2). I do not think this is normal, is it? Attached too is a show file that I saved at some point as I was trying to reproduce the problem. I cant recall exactly at what point, but maybe it will contain some useful information. Regards, Jean w1.zos

Hi Edward, Any update about your investigations? Yesterday I could reproduce the problem 5-10 times in a row (it's getting quite annoying as I was trying to do something else entirely). It always happens when I play with RigSync, for instance detecting fixtures, then pressing Clear Desk in order to get rid of all detected fixtures and be able to do it again from scratch.

Yes I was. This is precisely the problem : RDM does partly work with those splitters, but I guess there are a lot of packet collisions due to the poor implementation of the standard by the splitters, so the information received by the FLX is flawed, or partial at best. Thanks for the links, Il make sure to take a look. As for the RDM sniffer, this would indeed be a nice addition to ZerOS.

I already thought about your Splitter (no doubt that it works perfectly well, and the fix switch is a nice feature), but as I consumed the investment budget of my theatre for the next half century by buying the FLX and the 18 ETC S4 Lustr fixtures (it is quite a small venue managed in an associative manner, so money is not really flowing), I'm going to have to look for something a bit/much cheaper but hopefully still functional. I understand you can't really promote other manufacturer's products in this forum, but maybe another user might have a suggestion 😉 Anyway thanks a lot for your help, very much appreciated!

Indeed. I wrote to the manufacturer (Highlite), but I have little hope of getting an answer, let alone a satisfactory one... Do you or anyone else have experience with RDM splitters that work as advertised? I guess I'd better start looking for a replacement for my Showtecs, and if I could have a minimal level of certainty that the new devices will work as expected that would be a relief!

This actually was quite odd : I patched my 18 S4 Lustr manually, then activated RigSync and it added that fixture. As I do not have any other fixture in my DMX network at the moment, I suppose it re-detected one of the already manually patched fixtures. This actually is odd, as I guess RDM must use some kind of universally unique device identifier in order to talk to a particular fixture before its DMX address is known (or actually even after it is known, since it is possible that DMX adresses of several fixtures overlap and thus cannot guarantee unicast communication). So it should see the device is already patched. I've had some messages telling me that I could not make modifications simultaneously to RigSync and non RigSync fixtures (I was trying to change the personality of several fixtures at the same time). So I suppose there are two types of fixtures. It would be interesting to know what RigSync does with the manually patched fixtures when it is activated, and what becomes of the RigSync fixtures when RigSync is deactivated. Maybe the crash has to do with mixing manually patched fixtures and fixtures discovered by RigSync, leading to duplicates whose deletion upon resetting the desk is not handled properly (for instance by trying to delete a fixture that is already deleted -> some kind of null pointer exception)... This actually is one downside of the RigSync magic : when it does something strange, it is really hard to tell why it did that. It might be interesting to log somewhere the changes it makes to the patch and the rationales of those changes (if this information is not particularly secret), and make the log accessible to operators. That would help to increase confidence in RigSync!

Hi Edward, I managed to reproduce the issue. The show file is attached to this post. What I did : Open Setup Display clear options Press on Clear fixture files (which succeeds) Press on Reset desk -> both monitors turn grey, console reboot required to get back to normal operation Rig Sync was enabled globally and on universe 1 both times when the problem occured, not sure if this has anything to do with the issue. A similar issue happened shortly after as I was trying to load a show I saved previously (which I could then successfully load after rebooting the console, so probably not a corrupt showfile problem...) Jean crash.zos

Hi Edward. I managed to find the courage to test the matter further after tonight's long programming session. Regarding the splitters, using only one of them doesn't fix the erratic RDM behavior. I'm really starting to think those Showtec RDM splitters are a joke. I still must test the other splitter alone (maybe only the first one is faulty, but I had enough for today ) Thank you David, this would be a good solution, but unfortunately I'd like to use the second universe with RDM disabled for my non-RDM devices (dimmers mainly).

Hi Edward, Your reactivity is quite impressive, thanks a lot! In my case the second splitter is plugged into the first splitter's Thru port, so this topology wouldn't work either. However I am not sure I tried using only one splitter (not quite the solution in my case as I need 12 distinct DMX/RDM lines, but still interesting to try in order to confirm that those splitters break RDM conformity when chained). I'll try that later today Have a nice day!