delicolor

Sorry, not the right file, I had too many I was tinkering with. shard 24.zfix

I should have mentioned I'm running 7.14.3 software. .zfix file attached along with mapping table. shard 65-24.zfix

I have a new moving light that I found a perfect match for in the library in 16 channel mode. If anyone is interested, the fixture is a Shard Bolt 65 zoom wash bought from SS&L and it matches to an OMAX OM-M450B which is not the same but has similar functionality (RGBW, zoom, 16 bit pan/tilt). The Shard also has a three cell ring head mode (outer 1/outer 2/inner) which uses an additional 8 channels for RGBW 2 and 3. After much trial and error, I noticed that when you move to cell mode the intensity channel gets nailed up at level 255 regardless of the default and all intensity control happens on the colour channels instead. It is possible to access .1 .2 and .3 cells individually via command line and colour them accordingly. Is this design intent? I noticed that if you set the intensity to cell instead of master then the chosen cell colour levels stay at default and the intensity channel fades up and down. (The other cell colours continue to behave as if there isn't an intensity channel). I also tested to a rudimentary 2 cell RGBI profile to rule out more complex interactions. (It was imaginary- I-R1G1B1R2G2B2 with my Dmx tester). This was tested on an FLX-S offline but also duplicates on Phanton-FLX. The fixture profile can be provided if required but I suspect an explanation is probable without it. Ian

I have seen mention over the years that the Eclipse came with a cigarette lighter built in, a story even mentioned by Rob Halliday in his classic gear column. However, I've seen two in the flesh (one of which I commissioned), neither of which had one. Both were the larger frame variant rather the low profile FOH style. I don't recall it in product literature either. My question is- Did Zero 88 ever fit or provide cigarette lighters on the Eclipse as an option? I've no doubt they existed out on the road but probably an aftermarket mod by hire companies. (Realistically they would need a separate transformer as I'm sure the PSU would not have the headroom for an extra ten Amps without impacting on the output stability). (To younger Forum users without grey hair, once upon a time most cars had a cigar lighter gizmo on the dashboard or console, you pressed it down and it popped up again after a short while and when you pulled it out it exposed glowing coils you could use to set fire to the smoking article of your choice. The receptacle lives on as the 12V accessory socket). I realise people who remember the 1980s products first-hand within Zero88 are probably in short supply as they will have moved on or retired. However hopefully there is a Company archive and a keen custodian who can research as they enjoy the history.

Sorry to lose you from here Edward, I wish you success in your career moving forward.

If the release is still some time away I'd be happy to Beta it at our venue (FLX with S24 as backup).

I sent something to Support@zero88.com on Wednesday and didn't hear anything back. Has it changed or is it a domain hiccup?

Mostly good news! This will make our S24 1U backup for the FLX 2U mostly seamless and open up the possibilities for pixel mapping. (We have to forego fixtures 49+ at the moment).

Thank you, I'll try it out.

Last week as it was valentines day, we had our movers with red heart gobos on a slow gentle sweep chase on the dance floor. I thought I would also add another look to the scene so changed the colours and recorded it onto the same fader as an additional cue. Pressing go whilst the first cue is running does cause the colour change, but the beams scurry to a different position before resuming the same movement. Is there a way for the chases to be in synchronisation so that the beams continue their sweeps and just change colour?

I've sent the file. I created a new file from factory reset Phantom 17.4.2 with one MP75, recording three cues on playbacks with primary colours & setting buttons to Go(fade). Frustratingly it is working perfectly normally! There is presumably something a bit more obscure going on and hopefully you can get to the bottom of it. Having worked in software support a long time ago I remember that actually duplicating the issue is often half the battle...

Hi Edward, thanks for your fast response. I have duplicated the different behaviour on Phantom Zeros, I had 17.4 installed and the expected actions took place, I then upgraded to 17.4.2, the snap colour changes were taking place as described, as observed on the DMX output. I'll send the showfile over before doing default testing in case it is an interaction of another setting.

We just noticed a change of behaviour with 17.4.2 on our FLX that impacted somewhat on a show at the weekend. We have been running the software since December but most of the shows are with passive states on the four multi-function keys so a bit of busking by the Boss at the weekend raised the issue. (I had done my usual functional regression testing of course). We don't use the stack- we busk the shows on the playbacks as our venue is an Organ heritage centre and it is rare that visiting Organists give us an accurate set list. (Or even the resident Organists for that matter!) We have a bank of ten playbacks that control four Elumen8 MP75 RGBW fresnels, used to light the console sides. Each fader has the four lanterns at 100% with various colour groupings. For historical reasons going back to Frog days the volunteers worked out that you only needed one fader up and pressing the button on any of the 9 other faders would give a smooth fade to the new colour state. It didn't matter if the state was already LTP triggered with the blue box on the monitor, you still got the smooth colour transition. It left the board in a bit of a mess LTP-wise but didn't impact the lights between simple shows. However, the Boss was surprised to see that sometimes pressing a button resulted in a snap colour change and it was unpredictable (to him) whether it would snap or fade. Yesterday I quickly realised that if a playback had already been triggered previously, selecting it again whilst still highlighted caused the colour snap. Rolling back to 17.4 showed it was the software rather than the showfile. The release notes for 17.4.1 mention ZOS-8696 which is related to playback trigger & release so that is the likely culprit. I don't know if it is a bug or an unintended consequence but would appreciate a workaround if possible. (I never worked out if the ZOS reference body text was accessible to users). I can provide a showfile on request but in the meantime I will create a simple show on Phantom to duplicate it at home.

Cheers Edward.

Did the battery replacement article ever get written? I’m starting to get NVRAM errors on my 5 year old FLX. I see the manual confirms what screws to remove but not the innards. Ian