Making individual Vi's?

[pierroil]

Hey everyone,

This is more of a simple development question.

I have this motor controller that I can control via RS232 (yay easy). However, it has over 70 ASCII commands (it does a lot of stuff).

Each command has a similar syntax that can vary slightly but generally are in the format

<a>AAAnnn

Where <a> is the address (1 to 8), AAA is an ASCII command and nnn are integers. Some commands don't even need the address or the integers.

At the end of the day, I'm not trying to control the motor via a manual interface where I type commands, if I was, I'd simply let this go and use the simple Read and Write VI to do my application. I'm essentially looking to program a chain of commands for this controller and automate some process at the lab.

I was wondering how you think I should develop the VI's for this.

Should I make 1 VI fo reach command.

This would mean each VI has the read command but it would have the ASCII string already embedded within the VI.

Or should I simply stick to making 1 write VI (including all the concatenation I'll need) and stick to sending it the commands I need when I need them. Either way, I imagine at the end of the day, I'll be sending commands through Case structurse and event structures and I'd be hard coding what I send and when.

I have some ok experience with labview, just never had to deal with so many commands. Ultimately, I might use up to 20 of thme for my final design.

Many thanks!

[crossrulz · Accepted solution]

My experience says to make a VI for each command.  Each of these commands should be calling the same subVI to send the command and recieve the data.  Still in the command VI, decode the recieve data and have a simple output for your main program.

[pierroil]

Yeah, I was thinkign that would be easier than making a modular decoder.

Thanks.

[SteveChandler]

Something else to keep in mind is that you should consider putting all of these VIs in a library. Not an llb but a lvlib.

But an even better library is a .lvclass. First off let me apologize in advance if you are already familiar with LVOOP. But your question just screams for this.

If you have a base class that all of your commands inherit from then you can build an array of commands. You could iterate over this array and call the execute method that each command subclass overrides. The execute method for the correct command will automatically be executed for each array element with no need for any case structures to figure it out. The nice thing is that if you add a new command you just create a new subclass and do not have to touch any other code.

For more information you can check this out http://lavag.org/topic/11218-excellent-intro-presentation-on-object-oriented-programming-in-labview/

After you get the idea then you might find this useful http://zone.ni.com/devzone/cda/pub/p/id/1506

Take a look at the "Command Pattern" in that second link. Notice that they just dequeue an object and call the execute method. If you were to double click on the execute method it would not open a block diagram. It would open a list of possible VIs. In your case the list would be a list of your commands. If you ever create a new command it would also show up in this list.

[pierroil]

Never used LV Object Oriented. 

Now that I think about it, it might be a good idea. I haven't coded in OOP (java) for 4 years now so it didn't jump out at me. 

I started making these individual functiosn and for now it<s just in a folder. Was thinking of bundling them in a project file or library. 

I'll check it out!

Thanks!

[SteveChandler]

If you have some experience with OOP in Java it should come back to you. Basically all there is to it is that a class is nothing more than a library with a cluster and some VIs that can unbundle from and bundle to the cluster. Obviously there are more features but that is the heart of it.

[pierroil]

So what I actually have is this motor controller who can take up to 70 different motor controller commands (through RS232). 

I understand your point, but could I not just simply call the command VI block diagram whenever I needed.

I guess that would make my code really complicated wouldn't it?

So then, my last question is.

With your method (using the command pattern). I would essentially write an array of strings, which would flow into "write UI config" then be queued, then execute that command based on the VI's I developped. I would be skipping over the step where I would have a loop around huge case structure and my array of commands would flip through that 70 case structure?

I guess this would avoid the entire problem of all the tunnels being connected as well as adding in cases by simply creating the command. Execute would do the rest...

[pierroil]

Found the examples folder for LVOOP.

Looks like I know what I'm doing for the rest of the day!

[Dennis_Knutson]

You should look at the instrument driver guidelines. I personally hate drivers that use a single VI for each command. I think it is better to bundle some together. Look at some of the existing drivers and see how some functions send multiple commands. This is common for configuration functions that get called once where stringing several individual VIs is just a pain. Imagine calling several VIs to set a DMM's measurement type, range, etc.

[SteveChandler]

Yes, if some of your commands are always called together this is more convenient. If that is the case you could make a configuration or initialization VI that contains some the command objects, and that would sit in the API section of the instrument driver model.