Jump to content
Vari-Lite Controls Support Forum

Edward Z88

Vari-Lite Admin
  • Posts

    3,281
  • Joined

  • Last visited

  • Days Won

    81

Posts posted by Edward Z88

  1. Hi Steve,

    3 minutes ago, Gingersteve91 said:

    The macro is referencing a beamshape pallet for our Mac 300s & 250s/250+s lamp on value in the "shutter, strobe, control" encoder wheel.

    Apologies - I thought you were creating this fixture macro using the Fixture Editor. If you create a custom macro which recalls a Beam palette, this will not automatically stagger the lamp strike. Fixture macros cannot be created manually on the console.

    If you would like access to the "legacy" version of these fixtures with the Lamp On macro, individual Martin fixtures can be downloaded from the link below...

    https://zero88.com/fixtures/legacy-library/Legacy library (gft41.0)/MARTIN/

    If you have any questions, please let me know.

    Edward

  2. Hi Steve,

    Lamp On macros will automatically strike each fixture one after the other, if the macro is named "Lamp On". If the macro has a slightly different name, the macro will run across all fixtures at the same time, and will not be offset.

    I hope this helps, if you have any questions let me know.

    Edward

  3. Hello,

    16 hours ago, Aniaki said:

    Ok to record on beam palette, but it's not possible on macro ?

    It is possible to record a macro of the fixture being selected, the custom beam palette being applied, and then the fixture being sent back to defaults again. You can then use this macro which will select and Lamp On your fixture.

    16 hours ago, Aniaki said:

    To be honest, I had the command in my macros, but I don't know why, it disappeared ?

    The fixture macro for Lamp On for these particular fixtures is no longer included in the recent ZerOS Libraries.

    If you have any questions let us know.

    Edward

  4. Hello,

    Welcome to the Zero 88 forum.

    6 hours ago, Calebhc said:

    At the theatre I am involved in we have the FLXS48 desk currently using 7.9.8. It is awesome.

    Really glad to hear you are enjoying FLX S48.

    6 hours ago, Calebhc said:

    I did some digging and found from another discussion that it was an issue with the software. So I followed the instructions, made a backup of the desk and updated it to 7.9.9. I was then unable to load the back up from 7.9.8 onto 7.9.9.

    Do you have a copy of the show file (.zos) that you saved in ZerOS 7.9.8, and are unable to load into ZerOS 7.9.9? If so, please email this to support@zero88.com, and we will be able to advise.

    If you have any questions let us know.

    Edward

  5. Hi Rob,

    9 minutes ago, RobTag said:

    I was wondering, seeing as the FLX S48 has both 3pin & 5pin outputs, could I use the 5pin as normal, but connect the LED lights via the 3pin output directly without having to use an adapter?

    Yes that’s correct, both the 5 pin and 3 pin XLR connectors output DMX. If you have a 1 universe FLX S48, both ports will output universe 1. If you have a 2 universe FLX S48, the 3 pin will by default output universe 2. This can however be configured in SETUP -> Universes. 

    Hope this helps,

    Edward

  6. Hello,

    Really sorry to hear this, many thanks for the description of the issue.

    Please email your show file to support@zero88.com, and we’ll be able to take a look to see if there’s an indication of the cause. 

    If you have any questions let us know. 

    Edward

  7. Hi Paul,

    If there are faders that don't seem to be registering correctly, I'd recommend booting the console into Test Mode. You can access Test Mode by booting the console with the SETUP key held down. This will show you an on-screen representation of the console on the internal touchscreen. You will then be able to work through all of the console's faders and buttons, and ensure that the physical position of faders matches the on-screen representation.

    For more information on Test Mode see the link below...

    https://zero88.com/manuals/zeros/trouble-shooting/test-mode

    If some of the faders are not synchronised with the on-screen representation, and are registering incorrectly, as @kgallen suggests, I'd recommend using a can of compressed air spray, to clear out any dirt from the fader tracks. Do not use an oil-based lubricant.

    If you have any questions let us know.

    Edward

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

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

  10. Hello,

    Welcome to the Zero 88 Forum.

    16 minutes ago, Newman_says said:

    Can anyone tell me if there is a screen (LCD monitor) available for the Jester 24/48 zero 88?

    Jester consoles have a VGA output on the rear panel for an external monitor output. Any monitor with a VGA input should work with the Jester.

    If you have any questions let us know.

    Edward

  11. Hello,

    To Lamp On the Mac 550, select the fixture, and tap "Beam" to go to the Beam controls. Then dial the "Shutter, Strobe, Control" parameter until you reach "Lamp On". If you are on a FLX range console, you can tap the middle encoder button of the "Shutter, Strobe, Control" parameter, and then choose "Lamp On" from the touchscreen. If you wish you can then record a Beam palette, to give you a shortcut to the Lamp On command.

    Hope this helps,

    Edward

  12. Hello,

    24 minutes ago, EwenA said:

    Is it possible to edit a single playback live, and exclude other active playbacks from being incorporated into the updated cue?

    Yes it is. To do this, when you update the cue, you can disable the “SmartTag” option in the Update options. When SmartTag is disabled, only manual control values will get included, not values form another playback. For information on the SmartTag feature, see here…

    https://zero88.com/manuals/zeros/cues-playbacks/record-options/snapshot-smarttag#smarttag

    Hope this helps,

    Edward

  13. Hi Jean,

    1 hour ago, Jean Iwanowski said:

    I understand you can't really promote other manufacturer's products in this forum, but maybe another user might have a suggestion 😉

    Let's see if others have any suggestions. It may also be worth a post on the Blueroom technical forum for a wider reach of product suggestions...

    https://www.blue-room.org.uk/index.php?showforum=2

    1 hour ago, Jean Iwanowski said:

    Anyway thanks a lot for your help, very much appreciated!

    No problem at all - just let me know if you have any questions.

    Edward

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

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

  16. Hi Jean,

    8 hours ago, Jean Iwanowski said:

    Regarding the splitters, using only one of them doesn't fix the erratic RDM behaviour. I'm really starting to think those Showtec RDM splitters are a joke.

    That's frustrating. In this case it does seem like these splitters are not truly RDM capable.

    If you have any questions let me know.

    Edward

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.