JackHamilton

Sorry to chime in late here. Done lots of cRIO TCP/IP data streaming apps. Some tips. 1. Use Queue's to buffer data between acquistion loop and TCP/IP send loops. 2. Code the TCP/IP yourself - avoid the RT FIFO - they work, but not very hard, they don't expose all error conditions. 3. Download *Free* 'Robust TCP/IP" from www.labuseful.com it's a proven robost TCP/IP send and receiver model. 4. Be aware that you can CPU stare threads in the cRIO system!, you're not in Windows anymore, you've got to write very clean LV code with not alot of VI server tricks!. Regards Jack Hamilton

Be cautious when "Always" wiring the Error In cluster as a rule. Most functions will NOT execute on an input error. This can make error recovery fail, such as Closing a Reference...the Close will NOT execute if the input error = TRUE. In general I do NOT wire the error inputs of : Enqueue operations, Init Ports, Close references...

Dave, You should NOT have to put a wait between GPIB functions. The GPIB Serial poll is the way to poll the instrument for the MAV bit (message avaliable) and then you should perform a GPIB read it the GPIB serial poll reports bit 64 is ON. You need to look at the documentation for the Keithley instrument and look at the layout of the Serial poll register - one of the bits should flag when the instrument is done executing a command, or has data for you to read. You don't need a sequence structure - just have the GPIB write - then a small while loop with the GPIB serial poll inside - then the GPIB read on the outside right. The while loop should exit on the MAV bit set or and error from the poll function. This is the fastest way to code this - it will run as fast the Keithely instruments can perform the operations. Regards Jack Hamilton I can help you with coding this if you have problems....

You're skipping a couple of subtle details. 1. The array coming from the waveform is U32 - and you're passing to the "byte array to array string" function which accepts U8 - so you're going to loose lots of resolution of your data, it will not even look right. 2. The typecast to string may work - as it will convert anything into a string - but they will include alot of non-printable string chars, I am not 100% sure they all go thru the serial port. (Simple to test) 3. If you use the typecast - it's important on the receiving side that the integer prototype on the covert from the typecast string is the right numeric representation. meaning if it's a U32 - then put a U32 numeric constant into the top input. Otherwise it will convert the string incorrectly and you'll have junk data. Item 3 - you can test without the serial port - just write the cast to string then recast it back to array and compare the graphs... Good Luck!

This bug with tables also occurs with exe's. not nice at all. I suppose setting the table if an indicator to "Disabled" might help. Regards Jack Hamilton

Reliable TCP/IP is not easy, goto www.labuseful.com and download "robust TCP/IP" this is a very reliable 24/7 TCP/IP connect, disconnect, reconnect VI set. (If I say so myself) Regards Jack Hamilton jh@Labuseful.com

If you're using LV8 make sure you have the 8.1 version of DAQmx - it was recently released, and did address the bug in the previous version. however, this is only if you're not actually trying to access the same hardware resource on the card more than once and especially when it's running. Jack

Randall, I don't EVER know of a good reason to save VI's without the diagrams - LabVIEW will cannot update the code to a different version - and it is impossible to recover the diagram. I would think the problem relates to the this. Regards Jack Hamilton

As I am giving lectures on Coding Architecture in LabVIEW I've been collecting these gems. Another example of "Extreme Data Flow Programming" this is aptly named "Run Away"

I agree and do not critize code, and believe me I see lots of LabVIEW code. I say any code that works is beautiful. I do take the gloves off when the client is in the difficult situation of think a 'few minor tweeks' are all that is needed to add: User log-in, data basing, etc. After a few years and a more than a few projects consuming 2x the time I quoted to 'refactor' the code - I'm pretty candid about the situation of a bad code platform. Of course the last person to touch the code 'own's it' so this is another reason for being open about the situation and biting the bullet about doing a ground up recode. Regards Jack Hamilton

Have the drawing saved in DXF or HPGL (plot file), which is plain Text ASCII - there are routines to open DXFs file in LabVIEW. There is a routine on www.labuseful.com that can open and display HPGL files. Regards Jack Hamilton jh@labuseful.com

I would not recommend trying to burn a CD directly from your LabVIEW application. The problems are not technical, but more an issue of making your code unecessarily complex and more prone to failure. For example: 1. Burning a CD requires that a blank CD is placed (by a human or trained primate) in the CD Drive. 2. The CD must actually be blank or have space for the data to be stored. 3. The CD could already have data on it so it would be adding data to the existing volume. 4. During the burn - a path or file with the same name could be added - causing a rename/overwrite prompt. 5. For whatever reason the burn could fail. Just trying to handle the 5 most likely problems that may occur associated with burning a CD - You could dedicate quite a bit of time creating a basic CD burn function with some rudedamenty error checking. It's common for some very nice working acqusistion code to quickly snowball into a Web access, database, reporting generating, eMail the user on error monsterous code, which will likely not do anthing well. Try to draw a line where adding features does not make the application fundamentally better. Adding features to make something easier for the user - is not always the best thing for the application. Many times is can only increase the chance the code will stop for errors. Take a look at the code size of a basic CD burning package and consider if you can do the same in a VI or two. That maybe the reason that CIT is charging 500 euros for the driver package. You still have to by Nero Burning. I've learned to try not to get caught-up in 'fluff' feature enchancements in code. I would really, really need a very good reason to add CD burning into LabVIEW. Regards Jack Hamilton

The problem with this situation when asked to fix or enhance code like is this analogy: You're handed a bizarre birthday cake, it was made by someone who doesn't know how to bake. You don't know if they followed the recipe, or used all the ingredients; more than called for or extra ingredients. They quite possible could have throw the frosting ingredients with the batter and bake it all together. You don't know what temp or how long they baked it. But! Your asked to make another one! :headbang: I also tell mechanical savvy clients "Working on code like this is like trying to overhaul a car engine that has been welded together"

Eventually, You'll get to the point of being asked to fix some existing LabVIEW code. Although this is not the worse I've seen, the sheer size of the block diagram is spectcular! Even on my wide-screen laptop 17" it still is several screen wide. Notice the liberal use of local variables! :headbang: