All Activity

It's not on the Wayback machine unfortunately @Archie D, but here's the old link anyway: https://common.zero88.com/a-z Sorry I couldn't have been of more help.

For each connector I would: - Remove the clip - Pull the IDC connector out of the receptical - Replug - Replace the clip Go systematically around the console doing this.

Hi, an update. Not too successful, but partially. We lay the console down, unscrewed the six access screws holding the front panel on, (i also put the earthing wriststrap on before doing this), and upon opening the console there was no obvious disconnection of the ribbon cable but we pushed down the clips to make sure it was secure. One was solid, the other flexed a bit on pushing. We then closed the console up, securing one screw top and bottom in the middle of the set of screwholes and turned it on. All worked perfectly. So we turned it back over, put the four remaining corner screws in, turned it over, plugged it back in, the fault was back. Do you think I need to replace the clip that had some flex in it? Do you think that is the issue with the intermittent fault on the LCD displays?

I've stayed away from it for now, but more recently I've noticed the desk will start freezing after about 4-6h of programming unless I restart it which isn't entirely ideal.

I'll have a look when I get home (I fear I may have deleted my bookmark), but that's a good shout

Hi all, from what I'm aware of (and the replies I've received), they don't seem to have any plans of getting the Android apps back on the appstore and for now are just sending the APKs out. I doubt we'll have any further updates to the apps at this rate.

Ordered yesterday, arrived today. I'll see if I can do anything tomorrow with the desk. Thank you again for the advice.

@pierotec That's good news. Thanks for sharing.

I can confirm that the Flx S48 console worked well using about 2000 channels with 2 Artnet node and 13 used universes

Only if I’m doing work on a board out of the system - in circuit, CMOS chips aren’t quite as vulnerable. I’m assuming you’re not running your feet on a nylon carpet first! But if you have a wrist band then might as well use it.

Thanks for your reply @kgallen, that's something great to go off if I take a look inside. Do you use an earthing wristband thingy when you open up your Fat Frog?

Just guessing but there is probably a ribbon cable dedicated to the displays (separate to wheels, buttons etc). I’m sure that was the case when I opened my Fat Frog a few weeks back. If you’re up for opening it I’d check that as a common cause - ie highly unlikely all LCDs themselves went bad at the same time!

Just an update - I've turned on the desk again to see if the issue had gone (due to intermittence) and I am now presented with this on the bottom LCD: However, when tapping C, B or P buttons, the top LCD goes back to normal instead of the offset lines as shown below:

Hi all, I have an issue with my JesterML that seems intermittent. It appears to only have started having this issue since a few days ago. The issue is when I turn on and boot up the desk, the main LCD is blank (but still backlit), same with the wheel LCD. The top MFK lcd is showing content, but slightly malformed on the top row (see pics below). Bottom MFK lcd seems fine so far. This issue sometimes happens when I turn the desk on, and sometimes doesn't happen. DMX output still works fine, same with monitor VGA output from the back ports. Buttons all still work, so do the wheels, as the red LEDs in the buttons do change when I press them to the desired option I want to select. It's the LCDs that are the issue. Another thing to add is that on the top MFK lcd, when I select either Colour, Beamshape or Position, the four horizontal bars you see disappear and it just goes to how picture E shows. Picture A: Whole desk view Picture B: The MFK LCDs Picture C : Main LCD Picture D : Wheel LCD Picture E: four horizontal bars have now disappeared after selecting C, B or P Pictures are attached below. If anyone knows the problem here, I would be incredibly grateful if you could help me. Thank you. Perhaps it is a loose connection inside, but maybe something damaged? I'm not sure. I wanted to be careful and not open the desk just yet in case something goes wrong. Picture A Picture B Picture C Picture D Picture E

I'll let you know soon 😉

No, but I've used nearly 1024 and that was OK although it was a few versions ago. Just wondering if anyone has gone further.

Why, have you noticed problems with more than 1024 channels?

Hi all. The iOS apps are now back on the App Store in their original capacity and under the same links they were before. ZerOS Monitor -> https://apps.apple.com/gb/app/zeros-monitor/id1033159176 ZerOS Remote -> https://apps.apple.com/gb/app/zeros-remote/id367342433 (cc: @Charlie Newman @Philh @ATC Tech)

Thanks David. I’ll give it a go with update.

I haven't tried what you are describing but my guess is that it's something to to with using 'overwrite" rather than "update". I think it is disassociating the playback from the pallette (as it would if you deleted and recreated the pallette). As a full FLX user, I'm not sure if you can do this but bring the playback up, select a fixture that should have values from the pallette and check the screen. If the playback is still associated with the pallette then the pallette name will show rather than numerical values. Same goes (I think) for the wheel labels. Obviously you could bring up the playback, select the fixtures, apply the pallette and update or overwrite the cue but that's going to get tedious if you have used the pallette in multiple cues. I'd suggest using update instead. Note that changing the group will not add or remove fixtures from the cue or the pallette. Also note, this is guesswork. I've not tried it. Hope it helps though.

Hello EVeryone, Please help as I must be doing someting wrong here... I have an FLX S48 running ZerOS 8. I create an "All Lights" Group and having selected that I create a "Look" and record that Look as a Snapshot (Shift+Record) to the Beam Pallete and I see that it says "ICBPE" in the pallete so I believe I have recorded all attributes of the look to the Pallette. I can bring back that Look on stage by selecting the All Lights Group and touching the approperate Beam Pallete. Having brought the Look on stage via the Beam Pallete I record it to a Playback Fader by Clicking Record and the appoperate Fader Button. Going into Playbacks and bringing up that fader puts the correct Look on-stage... So Far So Good. Later, I need to change the Look so set the new look on-stage and I re-record (shift + record) the same Beam Pallete and select "Overwrite" to record everthing. However bring up the Playback Fader still shows the previous look and not the new look on the Beam Pallete. Selecting All Lights and touching the Beam Pallete correctly brings the new Look on-stage. I understood that I could "reference" the Beam Pallet on the Playback fader and any changes to the Pallet would then automatically reflect back into the Playback Fader.. SO, am I doing someitng wrong or does that not work? Thansk Craig

Perhaps the crashes within programming are related to something memory-wise within ZerOS 8.0? You may be right there. I don't have a FLX myself, but as @SimonH mentioned, the desks running 8.0 crashed especially when programming moving lights, which usually handle more parameters than regular LED stuff and of course dimmers. I'm not entirely sure, but could the issue be related to where as you are programming a LX state, the data for parameters are held in some sort of temporary memory system (aka you know where in the output window, all the intensity values are red when not recorded/saved anywhere yet), and once recorded it never gets cleared from that internal memory as it usually should (due to the fact there is no reason to hold what you are currently programming, as it has been recorded) leading to the desk overloading itself to the point where the memory becomes full and eventually resulting in a crash. Obviously, once a reboot is performed, that temporary memory is cleared and all is well until the memory builds up again. Just a thought and a theory.

I've just had my FLX (running ZerOS 8.0) back from a 2 week hire and had no end of complaints regarding regular crashes I advised them to downgrade, but they were nervous to do so with a busy show schedule. I've also had a couple crashes during programming sessions, fortunately never when running a show. I wonder if it has something to do with the programmer?

Yes but the crucial bit is the bugs were ironed out.

Glad it's not just me. It all felt very rushed getting it out before Jon left and usually by now we'd be at least a half dozen releases on as the bugs were ironed out. fingers crossed that the regression brings back some stability.