Fixture Battery Proposal

[Verschwiegener]

#171

[Verschwiegener]

Needs Input on how to Map between Battery Runtime and Light output

[petrvanekrobe]

We will need to be a bit more specific, as many (not only Robe) fixtures have a battery (we will also have to distinguish between a battery and an accumulator (a rechargeable battery) which is used to power the display but not to provide power for the light output.

[petrvanekrobe]

Think about this... adding the battery as a property of the Properties Collect might end up like other previously added children there... not sufficient. As the battery is also wired, perhaps has fuses and so on, maybe it would be better for it to be a Wiring Object Attribute - ComponentType, either a separate, some kind of Battery Source, or under PowerSource? It could then get it's own properties, besides the already existing Power Source data. This would also remove the confusion about a battery for example for the display. Let me ad @klinzey here as they have currently been looking into this.

[Verschwiegener]

Yeah that's a good point. Though i thought that the Wiring Object Node was more for External Component that could be wired into the fixture.

[petrvanekrobe]

With the battery being a wiring object, pin patch could be defined. The question is whether applications are interested in that. If not, we could define it not as wiring object, inside the Properties collect.

Below i am tagging people/applications i am aware of which could be interested in that. We can decide based on their feedback/requirements.

@klinzey - Vectorworks
@moritzstaffel - Production Assist
@bartvanstiphout - PatchPrinter

[klinzey]

To me if it's internal to the device it would not be a wiring object, so it would be a property of the device. For me a wiring object is something that needs to be connected by the user. I asked the question of our connectCAD expert.

[petrvanekrobe]

Agree, but there are nuances...:

So this one is internal, right?

link

And how about this one? One base, multiple attachments:

link

[moritzstaffel]

We also have Fuses that are internal an internally connected. A Geometry seems to be the right thing.

[Verschwiegener]

Should the Battery be a WiringObject or a new BatteryObject(?) in the Geometry?

[moritzstaffel]

A Wiring Object seems more like the other, but the all the other Power Wire Geometries are for AC, while batteries are for DC.
So there is some challenge to connect them.

[Verschwiegener]

Other than that i think the Name "WiringObject" is much more associated with Wires that can be connected to the Fixture and Battery's would almost always be intern. So i think a new Geometry Object would be easier to understand for the user.
But that's just my opinion

[Verschwiegener]

When a Fixture has multiple Battery's that function as one should this also be specified?

[klinzey]

If the batteries are internal I think it should just be represented by a single battery. 1 or multiple batteries does not effect the functionality. I think we just care about the total capacity of the battery as it may effect run time.
I think if the batteries are external then they should be represented as individual batteries.
The other issue with multiple external batteries is that I think the wiring objects expects that there is a single power supply for an object and the distributor assumes only 2 inputs can't connected to the same output.

[Verschwiegener]

Just a bit of brainstorming

New WiringObject ComponentType "Battery"

New Attributes:
BatteryType: Soldered, Replacable, QuickSwap(?), External(?)
BatteryMode: Configuration, Operation
BatteryRuntime: Minimum Fixture Runtime on Battery Power Unit: Hours
ChargingTime: Charging Time of the Battery Unit: Hours

Changed Attribute Spec:
VoltageRangeMax: Voltage of the fully charged the Battery supplies
VoltageRangeMin: Minimum Battery Voltage the fixture functions with

I think that the Battery capacity would be irrelevant and should not be added because we would need to know the power consumption of the whole fixture in its different states to estimate the Runtime and at this point it is just easier to define a minimum Battery Runtime.

[petrvanekrobe]

I am still not clear on the use-case here, which will partially explain/dictate the requirements and what the application needs to know and what for. I would also like to know what am i describing - am i describing the battery inside the box or am i describing the box itself? Again, example:

https://www.robe.cz/liteware-satellite2
https://astera-led.com/products/runtimeextender/

Btw, @Verschwiegener are you planning to be at LDI by any chance?

[Verschwiegener]

For me the use-case would be to better model some gigs that i have that heavily utilize Battery Powered Fixtures. I would suggest that unless the BatteryType is External the Battery inside the Box would be defined, like with the Liteware Satellite 2. And with something like the Runtime Extender i would say that the BatteryType is External and because the Battery is not always the same the BatteryRuntime and ChargingTime Attributes would be left empty.

I'm not planing to go to LDI but depending on my University lectures I'm going to be at PLS.

[Verschwiegener]

I talked to a friend who works a lot with Astera Tubes, he said that the UN number would maybe also a good addition