Rolf Kalbermatter

Seems to me you want to scan a hexadecimal integer. That would be %x.

You don't get that guarantee anyways on Windows. Last time I did a check, the lowest timing resolution of loops under Windows was 10 ms, no matter if I used Timed loops or normal Wait Until Next Multiple ms. With a wait of 0ms I could make it go pretty fast but the Timed Loop barked on the 0ms value. A wait of less than 10ms definitely showed the discrete nature of the interval being usually near 10ms or almost 0ms if the code inside allowed the near 0ms delay. And no there was no guarantee that it would never take more than 10ms, there were always out-layers above 10ms if I did test for more than a few seconds.

You need to be a lot more specific. What is the problem? Why do you not want to use VISA? Did you write that DLL? Do you know C? For one, DLL interfacing requires a lot of C intimate knowledge to get it right. If you haven't that knowledge using VISA is definitely going to be much less painful and especially won't crash your application continuously during development (and quite possibly also later during execution of your application since any even small error in interfacing a DLL will sooner or later cause problems in the form of bad behavior or crashes). If you still want to go down the DLL route we need to know what doesn't work, what you have exactly tried and of course the entire documentation and header files for the DLL too, in order to even have a small chance of helping you. A DLL is simply a bunch of compiled code. There is no way to determine from the DLL alone what function interfaces it contains nor what the correct parameter types of those functions are. And last but not least even the header file of the DLL doesn't describe how buffers need to be allocated and freed when calling the function so there usually needs to be some extra prosa text documentation too that describes this. Your first post is analogous to me posting a picture of my car and saying it doesn't work, please help me! only clairvoyant people with an understanding of car technology could possible have an idea what might be the problem. But my crystal ball is currently in repair and I need to do it with what other mere mortals have available .

Definitely echo JKSH's post. As a rule your diagram should not use more than one screen. That makes life a lot easier not only for nudging out those wire bends. This rule was even valid back in those days when you had only 1024 x 768 pixel screens.

You should post in the correct forum topic. This is for providing code that others can use, not for asking questions about (possible) errors.

"IDN?" is a IEEE-488.2 specific command. Only devices implementing this protocol will recognize it and answer meaningfully. Most serial devices out there will NOT implement IEEE-488.2. Only typical measurement devices from manufacturers also providing GPIB options with their devices usually go to the extra length of implementing a real standard. Everybody else simply cooks up his own protocol. Why don't you try to send the commands to your device that you also tried with HyperTerminal? Just don't forget that HyperTerminal will be default convert your Enter key that you press to send of the command, into a carriage return, line feed, or carriage return/line feed character sequence and send it at the end of the data. You have to append the according \r, \n, or \r\n sequence to your command in MAX to achieve the same. And also do this same thing when you write data in LabVIEW using VISA Write.

Basically changing the value over Active X is equivalent to the VI Server method "Control Value.Set" which takes a label name and the value as a variant and then "pastes" it into the control. This does indeed not cause an event. The OP probably detects this by polling the controls for value changes and then generates a Value Change (signaling) event. If the user now operates the frontpanel, there will be an event from the user interaction and another one from the brat VI detecting a value change. Basically there should be a way in the event loop to detect if it is an UI value change or a property value change. But I agree that an even better approach would be to route the control from the other app through its own "hidden" interface.

Well, it seems I should be able to do something here, sans Mac support, if I leave all the encoding stuff out. There is a potential problem about extended ASCII characters in filenames inside the archive that has existed since the beginning and caused some problems in the past that I was trying to tackle. But no matter what I try to do, it always turns out to cause problems somewhere. So I have started to remove all the encoding translation from the current version in order to get a version out that should be functionally at least the same as older versions of the OpenG ZIP library (but support the new 64 bit platforms and the RT systems). It will still badly fail for filenames that contain extended characters but I'm not really anymore sure it's useful to try to fix that. I might try to add later some simple conversion function on LabVIEW level to handle those filenames a little more gracefully when extracting an existing archive (there is no way to guarantee letter for letter matching between the original archive name and the resulting file name after extraction since LabVIEW doesn't support Unicode filenames yet) but it will at least extract the files to a similar name. As I'm going to ski vacation at the end of this week I don't think I will be able to create a fully featured OpenG package but will try to post a preliminary and limited tested package here before that.

I was allowed a few minutes before the exam to sit at the machine in setup the preferences to my likings. Very important as I still use many settings as they were around LabVIEW 5.1 as default and hating certain things like auto wire routing and auto tool selection.

LabVIEW developers call your writers "stompers". They stomp on the memory they receive as input. The LabVIEW compiler is smart enough to not create a copy if only one data sink is a stomper. It schedules the code in such a way that all the non-stompers read the value first and then lets the stomper use the data. It goes even so far that an input can change its stomper status based if an output of that node is wired and may reuse that input value or is left unwired.

A wild guess but do you call any VIs in there that call into a DLL?

As I said, they may be working for your situation. But plugins tend to be a problem sooner or later. You can't usually just include your own VIs as the vi.lib directory is not present in an application. So you need the entire hierarchy but then you can't use any standard LabVIEW function that exists or uses a VI inside an lvlib or lvclass. With many of the LabVIEW VI libraries being turned into lvlibs recently, this is a serious problem.

One more advice: Don't use LLBs in your code development. It may be ok to do so for the final executable where you want to have certain libraries as container in an external file as some sort of plugin, but more likely you will want to use packed libraries for that anyways. The LLB fails badly for such solutions as soon as any of your dependent VIs are part of an lvlib or lvclass since LLBs can not contain these files so the VI inside an LLB is then broken as it misses its lvlib or lvclass file. Learned this the hard way when upgrading an older application that used LLBs as plugin. Suddenly most of the plugins were broken. Turned out that it failed as soon as a plugin called an AAL function as these got lvlibed in newer versions.

I know it was Michaels post and it wasn't really directly towards you. I fully agree that Release when Ready is the more accurate term in this. And Ready can mean a lot of things as you allude to. For a consumer application it can mean the application doesn't crash if started and used normally. For a mission critical system it really means, we have tested everything we could think of and then some more and could not find anything wrong with it and every engineer working on the changes has evaluated every effect that change could have as far as humanly possible. And ideally there was a real field test on some small scale to actually test the real world interactions too. A release manager can help manage that, but in many cases is just another person in a shorter or longer list of people who exists to dilute the responsibilities if something goes wrong.

A release manager wouldn't necessarily help. But the whole process of upgrading software certainly needs to be adjusted to the possible impact when something fails. Release small and often isn't the fix for this either. Even the smallest bug can cause such a mishap. And releasing small and often does increase that chance rather than decrease it. It also makes rigorous testing even more unlikely.

It doesn't!

It does depend a bit on the system you are working on. If it is the traffic control system of the National Railway company your better make sure that you don't add a fix that adds some regression in some seemingly unrelated area or you are likely to have been in the job for good. Our Dutch railway support organization just managed to create a country wide chaos this week when they installed a new version of the software in the system over the weekend which was supposed to fix something (or why wouldn't they even change the software?). Monday, the control system for the signals in the most important railway station of the country decided to shut down leaving the whole station virtually inaccessible for every train, causing a chaos over the whole country and beyond. The comment the next day in the newspapers was in the line of: We are very sorry, but we saw that already coming on Sunday after we installed the update! I'm sure the new software passed all regression tests they have (I can't believe they wouldn't do that for such a system ) but somewhere somehow something fell through the cracks that when it was stress tested on Monday morning in the commuter traffic, simply failed.

For Windows RT yes, for Raspberry PI running Linux not necessarily. NI Linux RT is already ARM based. There might be problems since the NI Linux RT devices use an ARMv7A based chip while the Broadcom on the Raspberry Pi uses an ARMv6, but the CPU on the new model 2 also seems to support ARMv7. So even that might be working. The only two problems about this are: 1) It's going to be quite a bit of work to port the NI Linux RT sources to run spotless on the Raspberry Pi 2. 2) It's pretty unclear about the licensing implications for the LabVIEW RT parts. While the NI Linux RT kernel is fully open under the GNU license, which makes it fully legal to take it and make it run anywhere you want, this can't be said about the LabVIEW runtime on those targets and of course the many drivers such as DAQmx, NI VISA, NI RIO etc. Especially the RIO and VISA drivers are absolutely mandatory to make the LabVIEW runtime even work on a target and for the seamless integration into the LabVIEW development system.

Actually the 64 Windows version is not the real problem. Haven't tested all but it compiles. What is the challenge is the various Linux variants at the moment.

You're doing yourself injustice. LAVA was anyhow created before the certification program, but that put aside, you don't need a CLA to be recognized as capable of architecting a solution. I'm not sure you read the thread on the German board but the poster definitely has greater problems than just being able to use the less than well architected driver. A basic LabVIEW course or at least working through a few tutorials would help a lot. I can't bring up the patience Gerd so dutifully demonstrates in that thread.

All NI email addresses are normally the <firstname>.<lastname>@ni.com. That should be correct enough to add to the sign up page for the Beta.

Crosspost from the German LabVIEW forum which has already a lengthy support thread about that. Asking here the same question is not likely to give you more information than what you already got, except possibly information that is so Advanced in content that it won't help . LAVA = LabVIEW for Advanced Virtual Architects

That might be a somewhat to categorical statement . Windows 10 is supposed to bring the worlds of Windows Desktop, Windows RT and Windows Phone even closer together, although I still have to see that happening. As such there is at least for the Phone and RT variant a possibility to run on ARM. However I wonder how licensing will work with typical Windows license costs many times the price of the Pi hardware. Of course the extra complication here is that LabVIEW for Windows is strictly x86/x64 so that won't help. You have a much higher chance to get the NI Linux RT kernel working on a Pi since it already supports Linux, so porting the NI Linux RT source tree to support the Pi hardware is "just" a smart pick and combine from the NI Linux RT sources and the Linux for RasPi sources.

LabVIEW does not expose an interface that would allow to load .Net assemblies dynamically. It is actually even so that any .Net assembly that was at some point loaded, will be kept loaded which can be troublesome if you want to debug a self written assembly and try to replace the previous assembly with a new one without restarting LabVIEW. Therefore your best bet is to create a .Net wrapper assembly that implements your plugin interface with one additional method Initialize() or similar that takes a path to the actual .Net assembly and object instantiation you want to use. Then load that assembly in that method and instantiate the object interface you want and store the object pointer in a private variable. All the other methods and property accessors of your wrapper simply forward their call to the actual implementation in the initialized assembly object.

Ohh, man. Now I know again why I didn't use the DOM Parser. This is insane and goes against all and every LabVIEW convention about destroying refnums. But there are other things in that API that make proper resource handling difficult to do.