ShaunR

Naaah. Downgrade to 2009. It's faster and you probably already have it

Expert (ɛk.spɛʁ) -> An old drip under pressure

Much more difficult than using a pic as a serial pass-through to just chop the break Not to mention <$10

*********************************** ERROR ************************************* ERROR: 3.1 kernels are not supported! ** Running a 2.4.x or 2.6.x kernel is required to continue this installation ************************************ ERROR ************************************ Thats as far as I got on 12.1 before switching to 11.4. I don't have a 2009 linux distro (rocking-horse droppings ) so unfortunately cannot try it to see if I get the same problem. All I can say is that 8.5 started ok and even installed everything properly on 11.4. Perhaps a call to NI?

this is what I did. 1. Goto YaST Control Center → Software → Software Management 2. View → Patterns 3 Select "Base Development" check box. 4. Install. After that I went to "Search" and typed in "kernel". Selected "kernel source" (which is 3.1 for 12.1 and 2.6.37 for 11.4) and then installed that. Like I said. I had problems with the NIVisa on 12.1 (which is one of the ones that needed the source and gcc) but no problems on 11.4.

http://forums.ni.com/t5/LabVIEW/Help-using-invoke-node-Ctrl-Val-Set-with-cluster-elements/td-p/887434

This is probably a case of the blind leading the blind but.... you've got a few errors e.g gcc Not found in current path*** ERROR: Some required tools are missing or were not found. ***[/CODE] I got a little further (since I have gcc and the kernel source installed) but then got this error [code] *********************************** ERROR ************************************* ERROR: 3.1 kernels are not supported! ** Running a 2.4.x or 2.6.x kernel is required to continue this installation. ************************************ ERROR ************************************ So I'm guessing it won't work (properly?) with 12.1. I am just going through installing 11.4 (which uses kernel version 2.6.x). NB: These errors were for only the GPIB and the VISA but I'm not going to faff around with seeing which "parts" might work although Labview did run without quitting (version 8.5)

Actually this is a slightly older one than I use currently. The latest one passes the errors via a queue to an asynchronous process that then writes the to DB but the main bulk of it is still the same.

I briefly mentioned a logging API that I've been using for logging errors, warnings etc to a SQLite database in the NLog thread. Since it seemed to be of interest, I thought I'd knock together a demo so that peeps could see how I use it and demonstrate some of the features using database enables above and beyond boring old text file logs (it requires the SQLite API for Labview installed) So here she is..... If people approve and think it's useful, I will add it to the SQLite API for Labview as an example.

Well. I've been around a bit.It's my 3rd most re-used piece of code. Maybe I should include it as an example in the API library

I do the same and insist on result data as well. I think you've just picked up on the error bit because of my last comment (my bad), but previously I did say log file with info, warnings and debug so I think we are on the same page. If the log table is in the same DB as the results then you get them by default when they send the file. A few MB is nothing really in the scheme of things and it makes no difference in performance for a database of couple of GB. Of course, with text files you would really be struggling even with 10s of MB, As to what you save in the log table, well that's just down to your category partitioning. The sort of info (comms etc) that you describe, for me, would be "debug" and only as and when required. Maybe you would just have an extra category "Comms" since categories are not mutually exclusive, But I would still want errors, warnings and info logged during normal operation and over extremely long periods. Because you can handle such large data files you can leave error, warning and info logging enabled permanently and just switch in the "debug" for all the low level stuff as and when required.You then get useful things like how often they restarted the machine, what operators were logged in when the errors happened, if there were any warnings before the errors occurred, any alarms emitted etc. And all filterable Of course. Errors should be minimal if the software is working as intended. So it's really info and usage I would primarily be interested in and I request customers send me the DB file every month for the first 6 months so I can see how it is being used/abused and what can be done to improve it. Quality departments love the info too since you are logging calibration and tool-change info over time and they can run data through their 6 sigma software I'm not sure I like the idea of including a database in a database. I don't really see the point since it wouldn't be searchable from the TDMS. Like with most things I prefer to stick with one technology rather than mix, If I were to consider it, I think I would just keep the Sqlite file separate or include the errors/info in the TDMS (SQLite cannot beat TDMS for streaming).

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.