LabVIEW
MAX launches multiple instances
Solved!
Well the "project that will never end" has officially become "the project from hell", my customer having begun calling it that. I had thought that I had gotten past the problem mentioned earlier, thought that I had gotten in down to one of my two USB to RS485 serial adapters, got the customer to throw more money at the problem and buy a NI dual port USB to RS485 adapter. The problem seemed to have gone away, but this week when we started really trying to get the system online it seems to have lept up again. I'm heading out the door to drive the 2 hours to the customer site to see what I can do today. In short, I have a program that uses on USB: an NI dual port RS485 adapter, an NI USB6221 Data acquisition box, a "LabJack" usb daq (built into one of the instruments I talk to), a USB Zebra printer, keyboard and mouse. I had started with most of the "instrument" USB on a powered hub, have changed the hub to a different brand, moved the 6221 to plug directly into the computer's motherboard USB, now have the NI Serial adapter also plugged into the MB USB, with only the LabJack (haven't really used it yet), mouse and keyboard on the other.
What I'm seeing is the loss of communications with my DAQ. I did implement the "-50405 reset" several months ago, and it "seemed" to help, but under the time constraints I didn't get to do a "scientific" analysis, did more of a "MythBusters" shotgun approach, with rerouting cables, moving ports, etc. I was only having the problem on the serial at that point, resulting in getting the customer to buy the NI product a month ago. But yesterday I was on site to add some "final" touches (until the next request) and hopefully release the system to be used when we got a flurry of DAQ losses. I also started getting a -50301 error, which I don't recall seeing before. One thing that I noticed was the little toolbar pop message that "a USB-6221 device had been detected, click here to use". I also saw two instances where a windows popup said something to the effect that "this device would perform better if plugged into a USB2.0 connection, with a tree chart showing what I presume is the MB USB, with the DAQ6221 highlighted in bold, and several USB ports (unused) in the tree> I'm guessing that this is indicating that something appears to be unplugged and then plugged, but it is driving me a little crazy trying to isolate where the problem is. To make matters worse (other than the customer warming up tar and collecting feathers) is that I am now officially on another project and so loose billable hours when I drive the 2 hours to this one. That is why I am rolling out the door into 9 DegF weather at 7:30AM on a Sunday morning.
Thanks for any thoughts.
Ok, more info, really getting desperate now on trying find a way to isolate the problem. I was at my customer most of yesterday trying to debug some hopefully final changes to my code, and figure out what was causing the USB related issues. Wasn't too successful at either, the system "glitching" interfering with the code debug.
The system is an HP S5120Y streamline desktop, dual core, with 4Gb Ram. I have a NI USB-6221 DAQ, a NI USB-485/2 and a Zebra printer all plugged into the USB connectors on the computer. I had a LabJack USB DAQ (internal to one of the instruments) but had it disconnected yesterday, and the keyboard and mouse, these last three on a powered hub.
The symptoms, as of yesterday:
I will be running my system which continuously is performing analog DAQ, at a not particularly high rate, gather info from a temperature sensor, humidity sensor, and four pressure sensors. Once the testing has started there are continous serial messages to a Hitachi motor controller and to a Lighthouse "Mini-Manifold/Particle counter" pair. The motor control messages are about once a second on average as it ramps up to speed, then only once every several seconds to check and adjust the speed, with each message consisting of a single, multibyte transmission. When the particle counter is actually being used there will be a series of setup messages, in Modbus protocol, then when it is sampling a continuous query message, at roughtly 400 mS intervals, until it sets a "new data" status bit, a flurry of messages (roughly 150 bytes or so) then a message for the counter to stop, then no more messages until the next test sequence. This exchange, depending on whether it a Daily initialization or actual test, may run for 6 minutes or roughly two. The motor control sequence, once started, will continue as long as the machine is on, following the above "a lot of messages, then few" depending on whether the motor has been commanded to a new speed or whether it as at its setpoint. The printer, when it gets used (I've only been able to get to that point once, so far, without having the problem failure occur before hand) is the data for a label. As it hasn't gotten used I doubt that it is the printer, unless it is when the printer is dormant.
What happens is, while the tester is running I will see a popup "USB Found" come up and then discover that I have lost comms with the DAQ and frequently, the serial ports. I had been having an issue with the serial ports suddenly being relocated (i.e. comm port 4 suddenly disappears and a com port 11 shows up in Max) but I had the customer buy the NI USB485/2 a month ago. I had thought that the problem was one of the two USB serial converters breaking down, but apparently not. Now, when I get the popup (and it goes away after a few seconds, so it might happen every time) I then get an error message, USB-6221 Error msg, -50301. This later error message indicates a problem trying to reset the DAQ, which happens in my DAQ code (using a variation of the code in the previous link) when I get a -50405 error, which apparently indicates that NIDAQmx has lost the "connection" with the resource being referenced. Occasionally I have gotten another Windows message (I didn't this time, so no image) telling me that the device plugged in would work better on a USB2.0 port, showing me a tree diagram of the high speed ports, with the USB6221 present and in bold. Not sure whether that is the device it is refering to, and if so why it thinks the port it is lugged into isn't high speed, since it is the same USB port, and the tree view shows it being one of the computer's internal hubs.
I'm really in a bind here, trying to get this project done so I can go back to earning an income, with my customer contacts catching a lot of heat from their corporate HQ, and then passing it on to me. It matters not that it most likely isn't my software, the system doesn't work and I'm the "expert".
Help me Obi Wan, you're my only hope!!
Would mention that the Zebra isn't unaffected by this "disturbance in the force", with it showing some weirdness in the monitor routine that installs with it. Hadn't noticed it before, but when I saw issues with the serial as well as the DAQ I looked at the monitor routine.
Thanks,
Are you saying that the front usb "jacks" are on a different bus than those on the back? Not sure how I can update the BIOS, it isn't on the network. I guess when I get to my hotel this evening I'll go to the HP site and see what is available. Almost to the point of going to WalMart or BestBuy and buying a new Dell desktop for them, would save me money, and definitely the grief. Of course that is if it fixed the problem! I'm, unfortunately, about an hour and a half away from them (can you say "Road Warrior"?) so I won't be there until tomorrow afternoon. I'm trying toget them to put the system on a UPS, am looking for some more heavily shielded USB cables than those that come with the hardware (the Zebra has a shielded cable with a ferrite collar at the printer end).
Is there a white paper or CAR or anything talking about HP computers being problematic? I might help to show them, I didn't spec the computer for this project, but am not sure what I would pick, didn't see anything called out about HP's.
Upgraded to DAQmx 9.0 in October, so that I could do the "reset" that wsa suggested for the -50405 errors. Only thing is now when I do the reset, it throws and error, saying the board isn't there. I'll look at the link.
The link is the same one I referenced in my earlier post, it is why I upgraded in October. I am using the "reset" that is described in that article, although it is more complex when you are using MAX tasks rather than doing it in LabVIEW. No luck, in fact I'm now seeing a -50301 error when I attempt the reset. Not sure if something has changed in the error, or whether I was just so lucky last fall that I didn't get the error -50405 that it attempts to clear. It seems to be doing it in an increasing amount, not sure what that indicates, some HW breaking down, change in the electrical environment of the test system, what. Really in the dark, using the shotgun method of doing a bunch of things, moving cables, etc., in the hopes that something will fix it.
