Multiplexing: Unusual API to send multiplexed messages.
juleq opened this issue · comments
The current implementation requires the user to append a ".[multiplexor value]" to the name of the multiplexed message that he wants to send.
IMHO requiring the user to just set the multiplexor value through the signal API and then call send on the message would be the more natural approach. And it does also work when extended multiplexing becomes implemented.
Can you give an example of the call flow you would expect?
I am a little bit rusty at the moment as I have not programmed on that application for a while. It is happily operational for 9 month in a few instances now.
I would propose this (pseudo-code; to make it more interesting, the message layout could be such that the multiplexor is not in byte zero but an arbitary signal of an arbitray position, length and endianess):
TheMessage.SomeNoneMuxedSignal = 42;
TheMessage.TheMultiplexorSignal = 666;
TheMessage.The666MultiplexedSignal = 23;
TheMessage.TheOther666MuxedSignal = 0;
TheMessage.Send();
Then, lets send the message with another muxor and corresponding value:
TheMessage.TheMultiplexorSignal = 667;
TheMessage.Some667MuxedSignal =111;
TheMessage.Send();
->Since the API does know that TheMultiplexorSignal is a multiplexor, it selects only the corresponding muxed signals and all non-muxed signals to pack during a send.
I do not know off the top of my head if you have the required back and forth references for muxor<->muxed signals already but when thats available it should be straight forward. The referencing model is comparable to the kcd and dbc models. They also have similar constraints with respect to multiplexing: Basically: A multiplexor is like a regular signal that has a multiplexor flag set.
For the implementation, having a flag (or reference) at the message level that indicates if a multiplexor is present will ease implementation.
Come back to me if I have to clarify my (rough) proposal.
Best and thanks.
I fixed the muxer with f2a547b, but it is (as per KCD) not an arbirtary signal (unsigned with offset, length only). Also setting the muxer first doesn't seem very intuitive as well.
How about adding an optional parameter to send function?
Ok, I am coming from the DBC side of things and canDB++ seems more (overly?) permissive with the multiplexor type. I think the KCD definition is the most appropriate.
The issue I had (as far as I remember) was that KCD allows multiple multiplexors (dbc lingo, that would be ‚Multiplex‘ in KCD terms) for a message. So one would have a collection of signal groups for such message. Thats what the .[muxor value] cannot do. And having multiple send parameters would be kind of redundant, because you could also just preset the muxor signals.
But I agree that optionally passing a muxor value to send() would be an intuitive approach as long as only one multiplexor per message is allowed. Just a note: DBCs do support nested multiplexors (at additional tooling cost). They call it extended multiplexing. But I just meant multiple multiplexors on the same level here. I think I have tried doing the latter with canDB++ but it did not seem to support that. I will verify that in ten minutes. If I recall correctly, then only KCD would support that.
Just checked, DBC does only support one multiplexor at a level.
I have no KCD tooling here. What do you use? Maybe we can check if that does support multiple multiplexors at one level. Maybe I misunderstood the schema? How would you interpret the cardinality of the ‚Multiplex‘ element for a message? It says: maxOccurs="unbounded"...
I just know CANoe and haven't seen multiple multiplexors yet. Also not sure how to implement it actually.
CANdb++ is the DBC editor of the Vector tooling. As such, it is shipped with CANoe, CANalyzer, etc.
I would cast my vote for just having that optional parameter that you have proposed then. I feel thats more intuitive than the .[muxval] syntax but thats just me...
I personally have seen extended multiplexing In the wild (rarely), but never multiple on the same level. The things I come across is power supplies, DCDCs, traction inverters, ECUs and the like. All of those are more the special purpose type of applications. I do not know if that is different e.g. for the automotive OEM folks. But those tend to be heavily invested in Vector tooling anyway...