Tim_S

I've got a request to take test records from multiple stations and put them into a central system (likely a database) to pull reports from everyone. We used to have software to do this, but it's now a dead product. My management wants to look at an "off the shelf" solution. I was wondering what people are using to perform reports (production summary, histograms, etc.) on their data. We've got a sister division that has used Diadem, so I'm somewhat aware of that and what we would have to do to get that up. We've considered a couple of vendors, which have their own issues. We've considered building our own again.

Another option would be to pass a message from your subVI to the top user interface when the subVI is done. You already are using an event structure, so passing a event would be a natural choice.

I've not tried using shared variables in a DLL. Is it not possible to keep the shared variable open between calls to the DLL? I would normally open the reference and putting it in a shift register for the next call.

We do the same thing as LogMAN: virtual machines for the older version. Initially the VMs get heavy use, but that tapers off as the older version installations become stable (few, if any, changes or warranty calls) or systems reach end of life. We have systems currently in the field that were built with LabVIEW 7.0, 7.1, 8.0, 8.6, and 2012 (there was much rejoicing when the LabVIEW 4.1 system reached end of life). We are looking to migrate to 2015 after SP1 comes out and will be creating a VM of 2012 when we do so.

I don't have v2015 to look at your code. You don't list what hardware you are using and your update rate. If you're doing this post-processing, then it should be very possible. If you're trying to do this live with millisecond update rates on a Windows PC, then it cannot be done.

That's a good point. I thought I was downloading the bitfile when the RT executable starts (using Download method), but was unable to locate the bitfile anywhere on the RT side.

Thanks. I would have downloaded from NI directly, but had to deal with the customer's network. I don't have a reason why RAD didn't work. It would always fail when trying to flash the bitfile. I dug up the logs with the two error codes I was getting in RAD: -2147220304 at nisyscfg.lvlib:Restart.vi -- NI System Configuration: (Hex 0x800404B0) Timeout while waiting for reboot. System is offline. -52003 at nirioFlashWriteBitstream.vi -- NI Platform Services: An unexpected software error occurred. The PC and cRIO have a direct connection. There are no physical network issues.

Still learning about the cRIO, but thought I'd share some of what I've learned recently. Some background on what was going on... We had a driveline failure on two test stands out at customer site. There are sheer pins in the driveline designed to fail rather than send massive torque through a gear set in ways that is just BAD as it can lead to dynamic testing of the hard guarding (which is always fun!). Long story short, there was a failure more of the sheer pins that required detection of the sheer pins breaking. Worst case conditions is the break occurs at 6000 RPM and the only thing that we have already in the system is a 1 mm wide match mark on a 25 mm diameter disk. We found some laser sensors that could pick up the mark and bench tested the system. Everything looked good, so we integrated the bench test in the project, compiled everything and went to update the cRIO. This involved adding C series modules (electrician on site) and remote update of the cRIO application and bitfile through TeamViewer. Lessons learned... 1. Install the NI-RIO driver on a PC connected to the cRIO before it is 1000s of km away. Transferring 4GB of installer over a flakey TeamViewer connection is not recommended. 2. Replication and Deployment (RAD) utility works well for the RT portion, but may not be able to install a bitfile to the FPGA. 3. The example "Get & Set Real-Time System Image" can work when RAD does not. Building the example into an executable that can deploy a selected file is very useful. 4. It is possible to create a image using RAD without errors from an identical cRIO that does not have all of the C series modules. There will not be an error, however the image will not deploy/set (sometimes without an error message). 5. Shared variables can function correctly with different LabVIEW versions (person helping me accidentally converted everything to 2015 for the image that did eventually install). I'm sure I'm missing something, so would appreciate any insight people have.

Last time I talked with a local sales rep (which has been a couple years now), getting the discount required a certain number of certified programmers and a minimum volume of purchase from NI. Any idea what the current requirements are?

I'm looking at publishing the current value to a set of shared variables and having the consumer handle the state changes.

Back on the third page of the discussion is CAR #313508.

I recall this one now... that could relate to shared variables as well. Looks like shared variables are based on TCP communication (yea for Wireshark). Not going to get WinXP on the machines. Win10 likely uses the same stack. Updating to LV2015 has logistical issues with trying to maintain same software at different sites. I'm thinking I need a different communication strategy to overcome this one.

I had this long paragraph but then stopped to think and started to smell something too. Yea, this could be race condition. In staring at the code, I'm getting a smell like I've gotten into a classic blunder ("The most famous of which is 'never get involved in a land war in Asia'") of making this too complicated.

I put in some more informative logging. It seems the counter was getting off because the message at end of test sometimes shows up twice when my laptop is on battery. Not a quirk I was expecting.

Rather than remove the .NET control from the test stand, I went back to my demo application. This is something simple that small-scale tests the various features. It is meant to run on a generic computer and is something a salesman could take on the road with no hardware involved. I added a counter in to the front panel that is incremented when the message at the start of test arrives and decrement it when the end of test message arrives. A timer was added to start a new test after the last is completed. My first test run went for 467 tests after which the counter was -43. There were various programs running (Outlook, Lync, Firefox...), the screensaver came on, and the computer locked during that time. The second test shut off all the extra programs that I could. This went for 87 test and had a count of -12. The screensaver came on and system locked, but I don't think that impacted the test (I recall having issues with such with Win95/98, but not since). I'm not sure I have a fresh system. Trying this after a cold boot is next on my list.

I appreciate the feedback and the technical explanations. I'm working on a way to prove the .NET control is the issue. Unfortunately, it's the only means we've been provided to control the UUT so this is challenging.

I've only done quoting for companies I've worked for, so take it for what you will. There should be markup. This covers any overhead you have that you can't bill the customer for. That can include R&D, capital purchase, advertising, licenses, lights, heat, coffee, accountants, lawyers, time between jobs, health care, sick leave... When I worked for a small, private company (<50 people) that was much higher than now working for a large company. Quoted price should also represent risk. A new customer is more risk. Lots of bleeding edge technology is risk. A customer that makes lots of changes in the project is risk. A customer who is going to take everyone's price and tell them they will pay 10% less at NET120 is high risk (strange how many companies sent back no-bid on that one).

I'm hoping someone has some deep insight before I start waving the dead chicken and invoking the arcane. I have two applications that talk to each other. One executes the test (sequencer) and the other is a user interface. These reside on the same computer. The two applications were originally talking through TCP where the UI would open a connection, register for messages, and receive messages from the sequencer at about 150 msec intervals. The UI would process the messages. and update the front panel accordingly. This ran into an issue where UI would not update smoothly. I was able to determine the UI was experiencing periods where there wouldn't be a message for up to 6 seconds. On the sequencer side, there were timeouts in sending the message at that point. The code already turns off Nagel. I poked through ShaunR's Transport.lvlib; I tried increasing the transmit and receive buffers on the sequencer side to no avail. I put a shared variable in the sequencer side and made the buffer 5 deep. This contains the same string that was being sent over TCP. I updated the UI side to read the shared variable instead. The update issues were solved. Or so we thought... This setup is going on five stations... two running one type of test (let's call these A) and three running another (let's call these B). The stations have, from the computer's perspective, identical hardware ordered at the same time and all updated to the same software level (operating system and all). This all should work the same. But it doesn't. There is an additional part of the message that only occurs once when the test starts. Reports are that the two station A will run 8 runs in a row with no issue, not get the message at the start of test for 4 tests, get it for 2, miss it again, and so on. We did see once a station B did this, but the three have run hundreds of tests since with no issue. A coworker has been checking this out on-site and tells me there are no errors or warnings with the UI side of the shared variable. The UI side has a 50 msec wait before a Read Variable with Timeout (timeout of 1000 msec), so it should run circles around the transmit side. To make things more confusing for me, there is an extra part of the message that only occurs once when the test ends. This always is received by the UI application. The sequencer and UI applications are something we've used before without issue. There is a customer-provided .NET control that talks to a Vector box (flexray to a control module) through UDP messages. I've Wiresharked that and don't see anything that will cause a problem with TCP or shared variables.

I expect the industrial computers I use (Advantech, Axiomtek, Nematron, Dynix...) to be 1600 to 3500 USD. Some of those are rack-mount with 14 PCI slots, some are panel mount touchscreen with three PCI/PCIe slots. A Dell desktop with similar specs will run 600-900 USD. Some companies perform serious tests to make sure the hardware and software work together without issue; this will cost more (Nematron does this). Some companies will assemble exactly what you order, even if it doesn't work together (Axiomtek sold me system with hard drives that were not meant to work in a RAID so the mirror was never created). Sometimes you think it's a supplier issue, but it's an issue everyone is having (there was an quality issue with the PCI bridges every backplane manufacturer used about 10 years ago). So far, the one that doesn't have a 2+ week turn around on warranty issues has been the most expensive.

LabVIEW is not my first language (my first was BASIC on a Radio Shack Color Computer 2), but it is the only one I have learned to where I use it professionally. No, you don't "have to learn". Can it be beneficial... yes. For me, personally, I interface with a lot of hardware and have been working with user interfaces. I've not programmed in other languages to do this, but I certainly have had to read other languages to find out how to do something. There have been times I've been trying to solve a problem that (at least at the time) had no ready-made-solution in LabVIEW; looking up algorithms in different languages and understanding what was being done and why it is done that way in that language allowed me to write an efficient routine in LabVIEW. For full disclosure, I have been taking an online course on C#.

I've used the NI 9411 before (the NI 9361 wasn't available at the time). Just glancing at the NI 9361 spec, that looks promising to use. The output of the flowmeter has a high voltage that is set by a supply voltage/resistor/zener combination. Recommend you check with your NI rep to make sure the hardware works. (I've run into undocumented gotchas before.)

This would use a counter input. Since you're totalizing, then you are just counting the number of pulses and multiplying by the number of L one pulse represents. The pulse width does not have an impact on the volume. The resolution of the measurement is one pulse, so there will be a measurement error of the volume one pulse represents.

One thing to watch for on USB is the maximum passive cable length is 5m for USB2 and recommended length of 3m on USB3. Using wrong, low quality, etc., cables could cause connectivity issues. Ran across this YouTube video on USB3 and cameras... it's a bit informative and a bit sales.

It sounds like you are looking for the "Voltage - Continuous Input" example.

Interesting. Been pondering something that would plug into a laptop as I invariably need an o-scope in the field at customer site and don't really want to lug a fill scope in luggage, though customer, etc. Something along the lines of this.