Support for "Extended Signal Multiplexing"

[Usamaahmad751]

It is also possible for a multiplexor signal to be multiplexed!
The logic already implemented in the parser library doesn't allow that.
The following JSON shows how this information can be a part of a Multiplexor Signal.

{
      "ID": 128,
      "Name": "XCP1_Dummy_TX",
      "CANNetwork": 3,
      "CycleTime": 0,
      "Signals": [
        {
          "ID": 128,
          "Name": "XCP1_TX_Data",
          "StartBit": 7,
          "Length": 64,
          "ByteOrder": 0,
          "IsSigned": 1,
          "InitialValue": 0.0,
          "Factor": 1.0,
          "IsInteger": true,
          "Offset": 0.0,
          "Minimum": 0.0,
          "Maximum": 0.0,
          "Unit": "",
          "Receiver": [
            "Vector__XXX"
          ],
          "ValueTable": null,
          "Comment": null,
          "Multiplexor": false/true,    <----- Is this signal a Multiplexor? 
          "Multiplexed":
	    {
	      "Multiplexor":"Multiplexor Signal Name",  <-------- The name of the multiplexor signal
	      "Value": 0X0                         <----- The Value of the Signal 
	    }		  
        }
      ]
    }

Further information about Extended Multiplexing can be found here ->

https://cdn.vector.com/cms/content/know-how/_application-notes/AN-ION-1-0521_Extended_Signal_Multiplexing.pdf

[Adhara3]

This limitation is intended at the moment.

Sorry
A

[Uight]

@Adhara3
any further preference on how to do this with regard to the 2.0 discussions?. Since the packer should have its own data structure the basic datastructure for the parser doesnt have to be particular optimized.

Linking orginal discussion: #76

I tried to summarize:

Parsing:
Phase 1: SG parsing
As the standard one, values will contain numbers extracted from standard muxing (i.e. m5, m0M) since at this stage we do not know if SG_MUL_VAL_ will be present.

Phase 2: SG_MUL_VAL_
We set the muxor name and we clear and fill values with ranges exploded.
If needed we can set Extended to true

Wrap up
Names are filled, so no action needed.

=> The order of parsing is currently fully depended of the dbc layout so doing this in two steps means that the sg_Mul_Val values are intermediatly saved in the dbc parser until the final Build method is called. The signal parsing result is by then allready present in the signals.

Data structure:
using [Flags] for Multiplexor None are Multiplexed so that a extended multiplexing can both be a multiplexor and multiplexed.

Multiplexor Signal (string? or just string notNullOrEmpty if the signal is Multiplexed)
(for a packer the build should be up to down not like above but thats the task of the packer to create; Here a multiplexor has no information which signals it multiplexes)

Multiplexor values as ISet or Readonlycollection of uint,
Basically a slight adjustment to:

internal class ParsingGeneralMultiplexing
{
  public MultiplexingRole Role{ get; set; }

  /* 
       For muxers the below is always null
       For standard mux info, the following is null at the end of the parsing but can be filled in the finish up
       phase by picking the only muxer expected in the message (if more than one, parsing error). Moreover for standard 
       the multiplexer value is filled with a single element, what is called group in the multiplexing info
       For advanced mux multiplexor signal is filled and multiplexer values are replaced (SG_ parsed values should be 
       overwritten)
  */
  public string MultiplexorSignal { get; set;}
  public ISet<uint> MultiplexerValue { get; } 

  // May be handy for checks in the wrap up phase. Should not be reported in the immutable public object
  public bool Extended {get; set;}
}

In addition i would also include a general info for a message it if is multiplexed {None,Normal,Extended}

Does that seem okay?
Ill probably do some of the stuff holiday season... ;)