ShaunR

Not sure I quite follow you here. If you are already using a DB for results, then just adding an error table is a no-brainer, The only difference is the db name that you log the error to. You also get the advantage that you can link a specific row (or test if you like) with one or more errors, info, warnings etc giving you greater granularity.

I think we all have something similar in our toolkit (although probably with not as many interfaces). However, a while ago mine got a face-lift to use a SQLite database instead of text files. The fact that you cannot open it in a text editor is far outweighed by the extra features like being able to filter errors to only show errors, info and/or errors containing certain text. It also means you can have much larger log files since after a program has been in the field a while, text editors struggle to open them. It also makes long term statistical analysis of the files much more agreeable.

Set the dialogue window to "floating"

No direct calls to a dll. I use this http://lavag.org/files/file/146-opp-push-file/ with the widcomm. If you are having difficulties, then you could try this http://bluetoothinstaller.com/

That's funny. I'm using the Widcomm one.

If you've got an android, you don't have to wait

http://tv.theiet.org/channels/ni/12076.cfm

Nope. It's obsolescence and having to upgrade to get bug fixes that keeps people buying Labview.

Isnt it "*IDN?" (without quotes) You may also be forgetting the termination character eg "*IDN?\r", "*IDN?\n" or "*IDN?\r\n"

I do?

Ok I'll shut up then. Obviously completely over my head

For reconstitution, I have a separate vi that is basically just a split string with a smaller footprint. This means that I can just cascade the splits to whatever depth is required. I found trying to do it in the actual queue vi meant that you end up either limiting the depth (n outputs), or with array indexing which basically is the same, but with a bigger footprint. For creating the message, I have just stuck to a string input (the ultimate variant). This has one major benefit over strictly typing and making a polymorphic "translator" in that you can load commands directly from a file (instant scripting). You can create easily maintainable test harnesses (load file then squirt to module) that works for all modules by simply selecting the appropriate file. My view on polymorphic VI's is that in most cases they basically replicate code, so the "user ease" benefit must be far in excess of the effort and in my case; I don't think it is.I leave that to others to "inherit" from my vis if they want that feature. Having arrays for inputs is fine on paper, but in reality it is no different. The user still has to create the array and uses concatenate array instead of concatenate string. Arguably he/she doesn't have to add the delimiter, but it's one of those "6 of one 1/2 dozen of the other" since if you just have simple, straight commands, you then have to build an array rather than just type in a string.

Perhaps start a new thread so as not to derail this one? (although I think we will just end up arguing about symatics).

I see no difference in terms of features or function, only in realisation and symatics. You've identified that it is useful to identify the target (and consequently the origin) and whilst you have used the "Slave1,2 etc I would think that later on you would probably realise that a vi name is far more flexible and transparent (with one caveat). By the way. I don't consider copy and paste reuse. I consider it "replication" and an "anti-pattern" (if the term can be applied in that sense). If I remember correctly, didn't suggest (incorrectly) that I would have to copy and paste to extend transport.lib and use it as an argument against?

I have already explained this in my original post. Top down design (and to a lesser extent bottom up) are the recommended design architectures. Why would that be? I believe I did say "architecture". Incompatible interfaces are generally an admission that you haven't fully thought about the design. If it's third party code, then you simply wrap it in an subvi which acts as the "adapter" and I use sub-vis to capture state without exposing internal details. They are "problems" specific to LVPOOP. Indeed. I vaguely remember describing it in another thread a while ago whilst I was investigating it. Now it's a defacto consideration in my designs. It's just a way of designing the architecture to maximise modularity and minimise points of interconnectedness (is that a word? ). Indicators, shift registers, wires, sub-vis. They all externalise "state". There is (generally, not exclusively) no need for "special" components or design patterns to capture state in labview, unless (of course) you break dataflow. Even then, they are merely idioms.

Uncanny. I haven't really been following the thread (so I may end up trying to eat both feet) but saw your master slaves post.......this looks virtually identical to my standard app designs. I found that using a colon separator (I started by trying to emulate SCPI command composition) means you have to write more decomposing/error checking code when you start sending paths around. (I eventually settled on "->"). May not be an issue with your stuff, but thought I'd mention it.

It's called "rounders" over here and it's played exclusively by girls Patterns aren't as important in Labview as they are in other languages. Modularity is far more of a consideration IMHO. With modularity comes re-usability and those patterns relevant to Labview are generally the glue that binds the modules. However labview is hierarchical in nature and in terms of architecture I only use one pattern (now)-the diamond. But you won't find it in any books. I use the terms "doodah" and "oojamaflip" quite a lot ("we'll use the messaging doodah for that DVM oojamaflip" ) Don't get too hung-up on terminology. It's a graphical language after all.

Just goes to show how popular you are

Interesting considering your handle (Asbo).

Shamar Thomas

No enum. The refnum is converted using the "Variant To Flattened String" to give a string and and array (which is clustered together). The type of refnum is encoded in the array as a type descriptor. The descriptor then decides which piece of code to execute and the flattened data is reconstituted for the particular primitive (TCP,UDP etc). It's just a way of removing the type dependency so that the refnum can be passed from one vi to another independent of the interface. It's all in the Tansport.lib if you want to see how it works. Whats the point. It's has been declined with 322 kudos .

No its not (an object). It's just a container like a string, int etc that contains raw refnum data. Why complicate it by adding 15 new vis just to read/write to it.

The sqlite binaries can be compiled for VXworks. It's something I looked at (and successfully compiled), but since I don't have a vx works device for testing; couldn't go much further.

Nope. That's the ARCLD (Analy retentive classical labview disorder). Those with OCOOD have to create a class project, sub-vis for all the methods and fill out a multitude of dialogues.

Yup. But my style is to have control labels to the left, indicators to the right and for them to be stacked closely to lessen wire bends.Of course. I don't suffer as much from the "obj" problem