05-14-2010 01:38 PM
polymorphic vi's handle all the rubbish, I agree it is more work to build the system but during usage you don't see the vi's, you only see the polymorphic base vi.
And they all can be created from one vi that has to be copied and only thevalue input and valueoutput have to be changed into the next type.
So LabVIEW handles everything except the the first one.
The gain is that you don't have to convert the output into the correct type making your real vi's easier to read.
05-14-2010 03:04 PM
I've built polymorphics before and it is a lot of trouble, so I really don't want to do this at this time. Please feel free to create a polymorphic version if you wish. I like the variant version. It isn't hard to convert the variant to data. I will look into using LVOOP as Ray mentioned. It may give the best of both worlds.
05-15-2010 03:08 AM
05-17-2010 10:55 AM
I'm not trying to beat up on your idea, Albert. Please don't get me wrong. It's just that I'm lazy. To cover all possible variable types, you would have to produce 15 polymorphics for numerics alone, then 15 more for numeric arrays, string, string array, boolean, boolean array, path, path array, enums, etc.... Over 40 in all. I'm way to lazy to do this. I'm afraid LVOOP will have the same problem, although I have not looked into it yet. Maybe someone could enlighten me on a way to not use variants without having to write a ton of code.
05-18-2010 07:29 AM
07-08-2010 12:50 PM - edited 07-08-2010 12:52 PM
tbob-
Just wanted to share another variant on your WORM. I switched to a feedback node and used variant atributes like Ton suggested.
Functionality:
1. Always check the WORM for the global and report it if found - otherwise pass out what was passed in.
2. Add new global if:
a - Global not found.
b - Global name is not empty.
c - Value In is not empth.
The WORM variant is not output.
Also, a little nugget I discovered - you can use the "Empty String/Path?" directly on variants.
07-08-2010 01:47 PM
Great suggestion. I will look into it when I get a chance. Today I hope.
07-08-2010 02:14 PM - edited 07-08-2010 02:15 PM
Globally initializing the feedback node on first call eliminates the need for the Select node...
07-08-2010 03:20 PM
I have incorporated the Variant Attribute scheme into the WORM Global. I like the idea, thanx Ton P. No need for an array.
Sorry, paulmw, I don't like feedback nodes so I used my good ole while loop with a shift register. I find feedback nodes hard to follow. Also, since your code does not produce proper error messages, I kept my architecture intact. So here is version 3 of the WORM Global.
07-08-2010 06:59 PM
No apologies necessary, just here to share... I've been using feedback nodes 'almost' as long as shift registers (to date my LV experience) and find them very useful, especially in FPGA code. So I find that recognizing their function is not too difficult. Being able to initialize the feedback node on first call is very handy.
In your latest version, I would recommend moving the initialization (or "delete all") on first call outside of the first case statement that checks for an empty Global Name. With it where it is there is the potential to not initialize on first call because of a possible empty string for the name. Of course it will generate an error if it is empty, but if you try to programmatically handle that error and retry, then the initialization never happens as intended. I've attached a modified version.
As to what errors are proper can be as subjective as the feedback node vs shift register. I did consider the error codes you generated and felt that they didn't warrant generating an error except possibly one: if the name was an empty string. The "found" Boolean I felt was a sufficient indication and thought that leaving it up to a higher level to decided if an error is needed based that indicator (when considering what was attempted when the VI was executed). For example, one may not consider it an "error" if Value_In had data for a global that already exists.