Potential bug / improvement suggestion

[Jean Iwanowski]

Hi,

I just received my FLX console (zeros v.7.9.9). I still have quite a lot to learn/explore but I already am quite fond of it! However I spotted two curious behaviors I'd like to submit here since I did not find any mention of them in the forums.

1. After patching my fixtures (not sure if I used rig sync or not) I tried the various clear options. On several occasions (but not always) I noticed that when clicking on "Clear fixtures files " and then on "Reset desk" both the internal and external monitors turned grey and only a power cycle could bring the console back to normal operation. I guess this might be a bug in the software.
2. When changing the type of a fixture, the user-defined name for that fixture is replaced by the library name of the fixture. This is a bit annoying since a common use case is changing the mode of the fixture, where one would expect the user-defined name to be preserved. Maybe an improvement for a future software version?

Regards,

[Edward Z88]

Hi Jean,

Welcome to the Zero 88 Forum.

32 minutes ago, Jean Iwanowski said:

I just received my FLX console (zeros v.7.9.9). I still have quite a lot to learn/explore but I already am quite fond of it! 

Really glad to hear you have just received your FLX console.

33 minutes ago, Jean Iwanowski said:

After patching my fixtures (not sure if I used rig sync or not) I tried the various clear options. On several occasions (but not always) I noticed that when clicking on "Clear fixtures files " and then on "Reset desk" both the internal and external monitors turned grey and only a power cycle could bring the console back to normal operation. I guess this might be a bug in the software.

Sorry to hear this. This is not an issue we are aware of. Would you be able to email us a copy of the show file you were using when you experienced this? Our support address is support@zero88.com

35 minutes ago, Jean Iwanowski said:

1. When changing the type of a fixture, the user-defined name for that fixture is replaced by the library name of the fixture. This is a bit annoying since a common use case is changing the mode of the fixture, where one would expect the user-defined name to be preserved. Maybe an improvement for a future software version?

That is correct. Currently when you change a fixture, the replacement fixture will use the name of the new fixture, not the original custom name. The ability for replacement fixtures to use the original custom name is logged on our system as reference number ZOS-10745.

If you have any questions please let me know.

Edward

[Jean Iwanowski]

Hi Edward,

Thank you for the quick feedback.

4 hours ago, Edward- Z88 said:

Would you be able to email us a copy of the show file you were using when you experienced this?

Unfortunately I was just experimenting with the console at the time the problem appeared and I did not save the show at all. If it happens again, I'll make sure to send the show file to the support address.

4 hours ago, Edward- Z88 said:

The ability for replacement fixtures to use the original custom name is logged on our system as reference number ZOS-10745.

Good to know. Is there any way to check your "system" for known bugs and feature/improvement requests in order to avoid reporting something already known?

4 hours ago, Edward- Z88 said:

If you have any questions please let me know.

Thanks a lot. I'am currently experiencing quite a lot of problems with RDM/RigSync used through DMX/RDM splitters, but this is off-topic, I'll start a new topic about it.

[Edward Z88]

Hi Jean,

1 hour ago, Jean Iwanowski said:

Unfortunately I was just experimenting with the console at the time the problem appeared and I did not save the show at all. If it happens again, I'll make sure to send the show file to the support address.

No problem. We will investigate this to see if we can replicate the issue. If you are able to replicate the issue, a show file and the steps you took would be very helpful.

1 hour ago, Jean Iwanowski said:

Good to know. Is there any way to check your "system" for known bugs and feature/improvement requests in order to avoid reporting something already known?

Our system is internal only, however we are always more than happy for console users to suggest features, and we can then either log the suggestion if it is a new request, or raise the priority of an existing request. Feel free to do this via the forum or email.

1 hour ago, Jean Iwanowski said:

Thanks a lot. I'am currently experiencing quite a lot of problems with RDM/RigSync used through DMX/RDM splitters, but this is off-topic, I'll start a new topic about it.

Will take a look.

Edward

[Jean Iwanowski]

Hi Edward,

I managed to reproduce the issue. The show file is attached to this post. What I did :

1. Open Setup
2. Display clear options
3. Press on Clear fixture files (which succeeds)
4. 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

[Edward Z88]

Hi Jean,

Many thanks for attaching the show file.

I have been using your show file, following your steps, trying various combinations, and have been unable to replicate the issue. I will continue to investigate this.

I noticed in your show file there is a fixture that has been discovered by RigSync called "RDM:0181". What fixture is this?

If you have any questions let me know.

Edward

[Jean Iwanowski]

2 hours ago, Edward- Z88 said:

I noticed in your show file there is a fixture that has been discovered by RigSync called "RDM:0181". What fixture is this?

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!

[Edward Z88]

Hi Jean,

4 minutes ago, Jean Iwanowski said:

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.

I have checked, and "0181" is the ID of the S4 Lustr. Therefore RigSync has found one of these fixtures. Interestingly, RigSync seems to be detecting that the fixture is in "Mode 0", which obviously doesn't exist. This is why the fixture is appearing with its ID name, not the true text name. Were you going via your splitters at the time? If so it sounds like RigSync has managed to get some data over RDM, but not the full picture.

7 minutes ago, Jean Iwanowski said:

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.

That is correct. RDM devices will report a UID, which in theory is not shared by any other fixture - a bit like a MAC address in the world of Ethernet and Wi-Fi.

9 minutes ago, Jean Iwanowski said:

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.

If you patch fixtures manually, that are then discovered by RigSync, the console has no information to tell it that you chose to patch those fixtures manually, and therefore it sees them as new fixtures. This will likely result in the DMX address of your fixtures being changed by RigSync. This is because it will see they conflict with "other" fixtures in the console - the ones you patched manually - and so readdress them over RDM. This is where segregating your DMX network, and choosing to use or not use RDM for whole DMX lines is beneficial. This also helps with ensuring non-compliant fixtures won't be affected.

When in the Fixture Schedule, it is best to change the mode of a single type of fixture at a time. For more information see the link below...

https://zero88.com/manuals/zeros/patching/fixture-schedule/change-fixture

14 minutes ago, Jean Iwanowski said:

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)...

If the console discovers your RDM fixtures, and you decide for those particular fixtures you wish to patch them manually, you could delete the discovered fixtures in the Fixture Schedule. Doing this, will mean despite the console knowing they are still there on the DMX line, it will ignore them, and know you don't wish to use them. Resetting the console, would allow RigSync to patch those fixtures again. For more information see the link below...

https://zero88.com/manuals/zeros/setup/universes/remote-device-management

16 minutes ago, Jean Iwanowski said:

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!

We do have an internal version of ZerOS software, which has a dedicated "RDM" tab within Setup for this log. Currently the information is very "raw", and not something we'd want to baffle a user with. Adding a nice RDM sniffer is definitely something we wish to add. This feature is logged as reference number ZOS-9042 on our system.

If you have any questions let me know.

Edward

[Jean Iwanowski]

2 hours ago, Edward- Z88 said:

Were you going via your splitters at the time? If so it sounds like RigSync has managed to get some data over RDM, but not the full picture.

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.

[Edward Z88]

Hi Jean,

1 hour ago, Jean Iwanowski said:

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.

No problem, and many thanks for the feedback.

Edward

[Jean Iwanowski]

On 4/22/2021 at 10:30 AM, Edward- Z88 said:

I have been using your show file, following your steps, trying various combinations, and have been unable to replicate the issue. I will continue to investigate this.

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.

[Edward Z88]

Hi Jean,

On 5/7/2021 at 7:31 PM, Jean Iwanowski said:

Any update about your investigations?

We are currently still unable to replicate this with our RDM test fixtures and your show file. This may indicate the issue is related to how ZerOS is handling the specific RDM fixtures connected to your console.

On 5/7/2021 at 7:31 PM, Jean Iwanowski said:

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).

Sorry to hear this. If there are any debug files or error messages shown upon rebooting the console, please do send these to me, as these will help indicate the cause of the issue.

If you would be interested in trying our beta software, to see if this solves the issue, please drop me an email.

If you have any questions let me know.

Edward

[Jean Iwanowski]

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 :

1. Click on Reset Desk, it works
2. Enable RigSync
3. Let RigSync discover some devices
4. 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)
5. 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

Edited May 11, 2021 by Edward- Z88
Removed video to save user storage quota.

[Edward Z88]

Hi Jean,

14 hours ago, Jean Iwanowski said:

Sadly no debug file or error message shown upon rebooting.

Thanks for confirming.

14 hours ago, Jean Iwanowski said:

Is there no log anywhere that can be extracted from the console to help understanding the issue?

Any known errors can be displayed by pressing Z -> System Information -> System Text. I don't believe this issue will be reported there.

14 hours ago, Jean Iwanowski said:

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 :

1. Click on Reset Desk, it works
2. Enable RigSync
3. Let RigSync discover some devices
4. 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)
5. Repeat the previous steps -> the problem happens again.

Many thanks for your time spent investigating this. Thank you for detailing the steps and taking images. Again, I have followed these steps, with your show file, and cannot reproduce the fault. This therefore indicates a specific issue with the handling of these fixtures.

14 hours ago, Jean Iwanowski said:

The attached video shows the desk's screen when the problem happens (sorry for the incorrect orientation).

Many thanks for the video. I have downloaded this, and then deleted it from your post, to save your forum storage space.

14 hours ago, Jean Iwanowski said:

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?

Upon discovering a fixture, RigSync will look at the fixture's ID, to see if that fixture is in the library. If it is, it will patch the fixture from the library. If there are multiple fixtures in the library with the same ID, it will create a personality for the fixture automatically, and give the option to convert the fixture to the correct library variant. I will take a look at why with these fixtures ZerOS is not automatically patching the library version. This is logged as reference number ZOS-10753 on our system.

14 hours ago, Jean Iwanowski said:

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.

Would you be willing to try a beta version of ZerOS software, to see if this clears the issue? The beta software does not contain a specific fix for the Reset Desk crash, however does include further RigSync improvements. If you'd like to try the beta version, please send me an email, and I will be able to share this with you.

Again many thanks for your time investigating this. We will do our best to replicate this with your detailed information. This issue is logged as reference number ZOS-10754 on our system.

If you have any questions, please let me know.

Edward