Mark Yedinak

I don't have a picture but my kids like to give me crap about having an engraved name plat eon the back of my HP 48G calculator. I do get some payback now though because my oldest will be attending Rose-Hulman Institute of Technology this fall. They are home of the "Fightin' Engineers". Their campus isn't exactly a geek free zone.

QUOTE (ShaunR @ Apr 20 2009, 04:23 PM) Didn't most versions of LabVIEW executables require the run-time engine? At least this is what I recall from as far back as LV 4.0. QUOTE (ShaunR @ Apr 20 2009, 04:23 PM) And what is this obsession with queues on this site? Since LabVIEW is inherently parallel in nature you always need some mechanism to pass data between parallel tasks and to synchronize them as well. Queues naturally do this. Unlike a global variable queues provide synchronization as well. In addition they are event drvien so you can avoid polling local or LV2 style globals. They are also very efficient with respect to performance.

Personally I am not a big fan of preloading the all of your executions states for a state machine. This type of action means that your state machine cannot be flexible during its execution to handle things like pauses, aborts and errors. I prefer to calculate the states on the fly and only queue a minimum number of states at one time. Generally I try to only queue multiple states when I am including general purpose actions which should not care about what the previous state was or what the next state will be (for example error handling or data logging). For multi-variable processing I use methods similar to what MJE suggested and will include a state such as "Determine Next State" in my state machine. Preloading all of your states isn't really that different than simply using a huge stacked sequence other than the ability to dymanically build the sequence. Also as suggested I would separate control of the UI (separeate while loop with an event structure) out from the processing state machine. If the UI needs to interact with the processing state machine it can simply queue the necessary actions. If they need to get processed immediately queue them at the opposite end of the queue.

QUOTE (torekp @ Apr 17 2009, 01:14 PM) Whichever way you go spend some time designing a good message format. If you do this early on it makes your life much easier in the future when you may need to add new message types or different data.

QUOTE (mesmith @ Apr 17 2009, 12:08 PM) That was my experience as well to some extent. We were trying to get synchronized bi-directional communication between a UI written in LabVIEW with code running under TestStand. When we tried to use shared variables we ran into lots of issues getting it configured correctly. Due to schedule constraints we abandomed the shared variables and went with network queues. In principal shared variables should work fine (they are essentially a client server model over TCP) but they do seem to be challenging to get configured.

You could also look at using network queues to pass data between the applications. One thing I like about the network queues is that they are event driven and you don't need to poll anything.

Another thing you might want to look at would be a X-control. It can in essence modify itself at run time. At least with respect to what is visible and what is not. All of your code using this X-control would have a single control/indicator and wouldn't need to worry about which version of the packet header is being used. Probably the best approach would be to combine the LVOOP object with an X-control.

You may not be able to get a free copy, at least not legally. Some specs simply are not available for free. I hope for your sake that you can find one for free.

Are you opening the file for write access or read only? I don't think you will get an error if you open it for read only but you should if you open it for write access.

QUOTE (ShaunR @ Apr 16 2009, 03:44 PM) Hey, charge the IrDA folks not me. After all, they are the ones charging for the spec.

It looks like you can buy a copy of the specification here.

I would agree with Jolt though that if you need to recreate the VI you should give serious consideration to rearchitecting it. The overall description of your VI does not sound like a very robust design and it certainly doesn't sound like it is very easy to extend. While you might say that it is not worth the time to fix it now you may find that maintenance over the the life of the application will be difficult and time consuming. If I ever have to go back into old code that is poorly designed to change something I generally will spend a little extra time to clean things up. This sounds like it might be a good oportunity to do that with your code.

QUOTE (Cat @ Apr 15 2009, 02:28 PM) If you don't want your user's to edit the files and since you already provide them with a means to edit them have you considered storing them in an encrypted format? This way they could reside in the application directory, you could name it something like myapp.dat, and ensure that no one hand edits the file. You could couple this with the -pref option and you don't have to worry about maintaining a separate "hidden" directory somewhere. There is a decent version of the http://zone.ni.com/devzone/cda/epd/p/id/3473' target="_blank">blowfish encryption algorithm posted on NI's discussion forum.

I reported a similar bug to NI a while back regarding the resizing of windows and panes. From what I was told at the time they weren't error checking there calculations or watching boundary conditions carefully enough. It was totally screwing up my resizing. I haven't heard of it being fixed yet.

QUOTE (mesmith @ Apr 14 2009, 09:39 PM) I am not sure you would run into too often these days but have you ever run into packing issues when loading your structure into the C code? I know back in the day different compilers could pack structures differently leading to different byte alignments of the internal storage. Since most computers are 32 bit these days I don't suspect that you would run into this much today but I know in the embedded world you could set compiler options that would pack structures ensuring that they have the smallest memory footprint possible.

You might want to consider modularizing your code and rather than copying frames of a stacked sequence (which stacked sequences in general are not recommended) turn the code of the frame into a subVI that you can pass in parameters to. Your program would be easier to extend. You may also consider bundling your indicators into clusters. If all of these indicators are visible I can't image that your user interface is very readable or easy to understand. Not to be harsh but your code sounds like it could use some major rearchitecting. The sheer number of indicators and the complexity of each sequence frame may be contributing to your crashes.

QUOTE (mesmith @ Apr 14 2009, 03:40 PM) Exactly. I have some old legacy code written back in the day on small monitors and that stuff is just crammed in there to fit on a screen. Also, I know that when I look at my old code I cringe at how it looks compared to the stuff I write now. Coding style matures over the years. It doesn't happen overnight and it takes some experience to figure out what works and what doesn't as well as what is good style versus crap.

There are several advantages to using X-controls. First, you can do just about anything you want with them (yes, there is coding involved) and your custom control is now a nice and self contained unit that is easy to reuse. I doubt there would be significantly more coding than what you would be doing using your sub-panel approach. However, when implemented as an X-control you can trigger off events using the event structure just like any other normal control. You can save the state of the control if you want so state information can be preserved. Most of the changes you have mentioned could easily be achieved using custom properties for the X-control. One thing that I have found very useful about X-Controls is that for complex controls that I ended up reusing often I was constantly copying and pasting code from one application to another or passing references to subVIs. With the X-Control I simply drop the control on the FP and I am good to go. It makes reusing complex custom controls much easier. It simplifies the UI for complex controls. If I was only going to do it once I probably wouldn't create a X-control but for things I reuse they are quite nice.

If you want to ensure compatibility couldn't you create a single binary buffer containing all of your data? If all of your data points are 32 bits then cycling through your array of 1000 data points and creating a single buffer with all of the data (4 bytes for each data point) would be a very fast process and when you read the data out simply dump every 4 bytes into an array element. Again, this process will be fast and you won't have to worry about NI changing the flatten to string format.

QUOTE (jdunham @ Apr 14 2009, 01:01 PM) Actually I should clarify this since I was burned using binary data. I used LabVIEW functions to write an array of clusters out to a file using the "Write to Binary File" VI. Admittedly I did this way back when in something like LV 4.0 or 5.0 and after an upgrade I was no longer able to read the data. I ended up writing a conversion VI. Since then I avoided using the "Write to Binary File" to directly write out clusters. NI may have gotten better about this but I like to know the format of the data will be consistent on disk so upgrades aren't a problem. So, the flatten to string may have worked but I don't make use of them too often. I apologize if this has caused any confusion.

I have been burned in the past using NI's binary save when as you mentioned newer versions were not able to open older versions. Since then I have generally created my own generic data format which would save the data in a format that I could use to populate a native NI structure such as a cluster. I would save each of my records in the most suitable format for the data. Strings would generally be a byte array which would allow nonprintable character to be stored. My records would contain a header which would define the total length of the record. Within that record the elements would be stored with a length and a type field follwed by the data it self. This is similar to the way variant data is stored if you looked at the raw data for a variant but since NI has modified their storage methods in the past I choose not to rely on it being a static format. Now if you are truly storing it in a database then your table or tables should use the appropriate data type for the individual elements of your data. You only need to write a read and a write VI which decomposes you data into the respective columns in your table and another VI which can read the data from the database and load it into your cluster. You shouldn't actually have to translate the data between types. Integers will be stored in binary format, strings can be stored as byte arrays, strings or blobs in the database. Other data can be stored in the appropriate format for the data as well.

Personally I like having the ini files available. Nearly all of the application I write will use it to store configuration data for the application. It allows customization of the application without the need to rewrite things. Some applications even use multiple ini files. The myapp.ini file usually stores the allowmultipleinstances=true setting and a history list of previous configuration files. The user supplied configuration files contain information specific to a single UUT or test configuration they have saved. I absolutely detest using the registry for settings. Besides, an ini file is more portable across platforms.

Here is a basic wrapper that would turn a queue (prior to 8.6) into a circular buffer. You can ignore the cluster with the exception of the queue and queue size. This snippet of code is taken from a general purpose dqGOOP log object. If you wanted to be safe you could put the dequeue in a loop to ensure that all elements past the maximum size would be removed. However if you manage the queue properly the queue should never be larger than the maximum size.

QUOTE (Aristos Queue @ Apr 12 2009, 09:38 PM) This is only true for LV 8.6 and above. Prior to that you had to write wrappers around the enqueue to make the queue work as a circular buffer. Otherwise depending on how you created your queue you would either have a queue that would grow until you ran out of memory or stop enqueueing data if the maximum numbers of elements was reached.

It would help if you could post either your code or a screen shot of it to see exactly what you are doing now. As for the way you are keeping your data I have to ask why you are concatenating the racer's name and time together. These are two independent pieces of data. By concatenating them you are treating them as a single piece of data which they are not. If this was done to solve your sorting issues I think you should revisit that issue and write the code to correctly sort the clusters. Combining the data to make the sort work may achieve what you desire but it is a bad way of getting there.