Best way to merge 2 case structures with hundreds cases each.

[Thang Nguyen]

I am maintaining the code of two controllers (cRIO and CVS) in a system. Each of them handle request from ethernet communication like a server with input is string data type. And each of them handle hundreds of message like that. In the future the number of commands can be increased. Now the fun part is we decide to merge these two controllers into one. I am trying to find the best way to merge these two case structures together and how to handle this better.

I am thinking about rewriting this using inherited child class to catch each command. But as I know this only work if I use the child on the client side too. In the future if I need to developer the client by different language such as Python, I am not sure how to send the command to match with side of server.

[ShaunR]

Merging them is easy. Make each one a subVI then use a case statement to switch between them. How you switch will depend on if you have a specific signifier for each controller command set or, worst case, you just test against a list of commands for each.

Is the comms string based or more binary?

[Thang Nguyen]

1 hour ago, ShaunR said:

Is the comms string based or more binary? It is string based.

 

 

[ShaunR]

I am a great fan of SCPI. I always try to get device developers to follow that standard. It makes different device commands  much more structured and interchangeable.

Failing that it is generally a good idea to manipulate string based comms as strings. It is much more flexible, more modular and the LabVIEW case structure takes strings as cases (make sure to make them case insensitive). Converting commands to objects will bloat your code immensely, cause it to run like a slug and ultimately difficult to maintain (IMO). That doesn't mean that you can't use objects, just not advisable for the driver aspect.

You state you have hundreds of cases. It sounds like each case addresses a command regardless of similarities-linear programming. My first port of call would be modularity rather than architecture. Take a look at what you can break out into shared modules between cases and even between devices. This is much easier with strings but you will be bound if they are objects requiring different base classes as you identify more similarities. This is why I said try and manipulate as strings.

Once you have a more modular rather than linear layout, you can then look at objects (for different devices?). If you have done the work above, a lot of the class override methods will be just a wrapper around a modular subVI. and, where they are completely different in execution, you can add the device specific functions or modify the input/output from a modular subVI to make it compliant with the device.

That is my advice. I'm sure others will have other thoughts.

[Thang Nguyen]

On 4/29/2022 at 8:12 AM, ShaunR said:

I am a great fan of SCPI. I always try to get device developers to follow that standard. It makes different device commands  much more structured and interchangeable.

...

That is my advice. I'm sure others will have other thoughts.

Thank you very much for your advice!

 

On 4/28/2022 at 12:30 PM, ShaunR said:

 

 

 

Edited May 1, 2022 by Thang Nguyen

[Yair]

I can't say I understood what you have exactly (an example might help), but assuming your case structures take the strings and then parse and handle them, I would consider using scripting to split it into VIs where the VI name is whatever you handle in the specific case. The VIs should all have the same conpane and then you can call the correct VI dynamically. I think I would prefer having hundreds of VIs to a case structure with hundreds of cases. If you know that the two cases have the same code, you can then simply move then to a single folder, or you could try comparing them to see what the differences are.

The scripting might be tedious and it might require some fiddling to get it in an EXE, but it should be doable.

[A Scottish moose]

My approach has been Class based inheritance.  Have a parent class that accepts the messages in a VI and then overwrite that VI with your children classes. Using inheritance allows you to make a decision on who gets to handle the command first. The youngest class in the hierarchy gets a chance to handle the class first before you pass it up (or not).  I find that it makes it easy to handle the "What do I do if both controllers handle the same command differently?"

 

As an example.

MsgHndlrParent.lvclass:core.vi

ControllerChild1.lvclass:core.vi

ControllerChild2.lvclass:core.vi

 

Child 2 would attempt to handle the command in it's overwrite of core.vi, if it can't send it to Child 1:Core.vi, and if child 1 can't handle it pass it to MsgHndlr for error handling.  Hope that helps!

 

Tim

[Mads]

We should have a native solution to this. I added it as an idea on the idea exchange...