Loading constant external constant parameters: Strict typedef vs Global Variable vs AE

[VinnyAstro]

Hi!

I am working on a CAN communication module for a specific system and I'm not sure what is the best practice for my CAN Frame control:

Right now it is simply a cluster of 4 elements (Function ID; Node ID (Function+node= COB ID); Command ID and parameter)

I'm bugging a bit on the command ID control:

I thought of using a Ring control, that way I easily associate a command to a Hex number everywhere in my program and that avoids any mistakes later by manually entering a wrong hex command. Problem is I have hundreds of commands to implement which might change a bit over time. (Most likely adding new commands, less likely changing hex value between commands or while adding a command an existing one has to change)

So I'm wondering what would be the best to do, so far I've can foeresee 2 to 3 options:

1. Make the Command ID Strict Typedef. Enter manually all the commands. These commands will then simply be propagated over the program. Whenever a change has to be done, simply open the typedef
2. Create a file based on Keys+Values (.ini; .xml or any other kind) load this file at startup and save the values in a array that will be then given to the ring control's property node "Strings and Values []"
   1. Save the values into a global variable that can be easily retrieved anywhere in the program but that could also other contain external constant parameters
   2. Save it in an AE vi whcih would be dedicated to this kind parameters (or not?)

What options have I missed? what do you usually do when you have to maintain and load external data like this?

Thanks!

Vinny

[AeroSoul]

I use both methods you described, but the typedef one only if i know things are very unlikely to change and the .ini file if i expect (frequent) changes.

I use config file to save all settings for my device (com ports, baud rates, software keys etc), occasional command (more of a preference really) for computing; these are then read on start and saved to AE to be used throughout application. 

EDIT to add: In the end my application is built into an .exe, so config files come in extra handy to pass settings around that can be changed by end user.

[VinnyAstro]

Hi AeroSoul

Thanks for your answer (and sorry for late reply...)

In the end I will most likely have to go with .xml because of file conversion from already existing documentation.

But actually, while my question was to load Command IDs into a Ring control or Combo box, I've realized that I will anyway have to manually enter >a lot< of them anyway in a case structure...

My system communicates via CAN, in-house customized into CANOpen. While PDO1 will be just setting some parameters, PDO2 to 4 will receive an answer, either by acknowledgement (COB-ID+Command ID+same parameters) or by telemetry.

So to analyze this dataset, I don't see how else I can deal with it other than by having one big Case structure for the COB-ID and then smaller ones inside checking the Command ID... That will be a lot of cases to enter manually.

[Mark_Yedinak]

Personally I would go with a class implementation. If the need to add new entries frequently I would look at implementing some type of plugin architecture so the code can be added at runtime by adding new plugins. This is relatively straight forward if you are using classes. For example, you can have dynamic dispatched methods where the VI name includes the command ID. You can build your list of commands at runtime by either reading a file with that data or you could also build that the command list by what plugins exist on the system. Your class could support meta data for the commands as well. Using such an approach you could avoid having to use the internal case structure that will continually need to be updated. You plugin implements the command specific functionality.

How is your application being used? What is it's purpose? This can affect the approach you want to take for the system.

[VinnyAstro]

Unfortunately I'm not able to use classes yet (still don't know how to programm with LVOOP and still don't have to learn it ...)

My whole architecture is basically based on the NI QMH template, and the more I develop stuff with it (and ask questions on this forum, the more I realize that I'm basically doing manually almost all of what the DQMH is doing automatically -_-

---

@Mark_Yedinak  a écrit :

How is your application being used? What is it's purpose? This can affect the approach you want to take for the system.

---

To be clear enough but not too much (for the sake of my employment contract) my system consist in a motor spinning a mass. There is an embedded software controlling this motor based on a lot of parameters (temperature, power available PID etc.), including human interactions (Set speed and acceleration for instance) via an application that I am developping right now, and my software will also get a lot of telemetry from this system.

This is still the development phase. That's why some commands are for now likely to change but it should tend to some stability over time, even though it is still possible that one or two commands are implemented here and there over the years.

It is then definitely not that much of an issue to add a Case in my case structure if a new command/telemetry parameter is added. But:

1. Kinda want to do things in a nice way.
2. It gets trickier to version control the interface document and also to track which computers have which version of the software.