Steve Morris

I have a program/executable that has been used on several Windows 10 PCs over the last two years or so. We went to set up a new laptop (still Windows 10) and now the attached PrintPDFr1 subvi is returning an error 32. I am using LV2018 32bit. I've been in touch with NI support and so far we haven't come to a solution. We've tried: 1. Adding a copy of shell32.dll to the build of the exe under always included 2. Modifying the subvi to specify the path to shell32.dll in the CLFN 3. Running as administrator 4. Changing the subvi to use the .NET method found here: Solved: Invoke Print File (Explorer) - NI Community 5. Using 'FileMan Print File.vi' in winevent.llb in the attached zip file They all work on my development PC and on a second laptop, but they all fail and generate an error on this new laptop. Has anyone seen something like this before and/or have any suggested fixes. Thanks in advance for any input, Steve PrintPDFr1.vi _labview_win_util_32.zip

Here is an option to check out: http://www.eyetalkshop.com/c-199-video-frame-grabber.aspx I started to work with one of these a few years ago when I was in a similar situation with some legacy analog cameras. The manufacturer supplied a set of LabVIEW vis to use with the frame grabber. Fortunately for me the client agreed to make the jump to digital, so I didn't get beyond the 'this seems to work OK with LabVIEW' phase.

I have an application that moves an assembly back and forth using a voltage analog output signal to an external motor controller to control the speed and direction of a DC motor. I'm using a counter connected to an encoder to determine the distance traveled and to determine when to reverse direction. Randomly I get error # -200088, 'task invalid or doesn't exist'. This can happen when I try to read the counter or when I try to set the analog output. Sometimes it will happen every time I start the program, other times it will happen after a minute of running, or after days of running. LabVIEW seems to forget the task. Creating the task doesn't generate any errors. The PC is Windows 7, the application runs as a LV2012 exe, the hardware is a cDAQ (USB version), and I'm using DAQmx 14.2. I've attached a simplified version of the program to show how I'm setting up the tasks. In the full version I start with a home routine and I count the encoder pulses to determine when to reverse and reset the count to 0. The full program also has some other 'unrelated' things going on: sending serial commands to stepper motors, reading some gas sensors, monitoring operator input, handling and logging errors, ... I have not been able to figure out why this is happening or what stops it from happening. Rebooting the PC and hardware isn't a reliable fix, nor is it desirable. Some history: At first I had the DC motor control encapsulated in a subvi and had two reentrant copies running two different assemblies, ran this way for several days. Started getting errors and removed the second copy because it wasn't needed -- error went away for a couple days. Removed the control loop from the subvi and put it on the block diagram of the main program -- error went away again. Ran fine for about three days continuously until the error returned on the analog output. I could run the simplified program (attached) without error, but the full program always gave the error on the analog output. Rebooting didn't help. Finally, out of desperation, I rewrote the program to create the task, write the analog output, and clear the task every time I updated the output. Error went away. It has been several days since the change and I have my fingers crossed, but I'm not convinced this is a real solution. Especially since I've had the error on the counter read as well as the analog write. Has anyone dealt with something like this, and what did you do to resolve it? DC simple test LV2012.vi

Llisas, If you want to learn LabVIEW take the job, IMO there is no better way to learn. When I first started with LabVIEW all I had were the manuals and a project. The result wasn't pretty but it worked and over the last decade plus I've expanded my LabVIEW skills and refined my technique as I've worked on many more projects. There are lots of resources to learn from: examples that ship with LabVIEW and the NI knowledge base being two of the best. I haven't dealt with audio files or Web Servers and have only a little experience with the cRIO, but the cDAQ is very easy to use. If you are willing to put in some late nights I would think you could do what you've described in a week or two (just my guess, your mileage may vary ). I've always looked at this sort of challenge as a no lose situation -- if it takes me longer than I estimated up front, my hourly rate went down, but in the end I've been paid to learn new skills. Before telling the client how long it is going to take you to do the job, I'd spend a few hours searching for examples that show you how to do the various functions you described and on NI's website looking for tutorials, white papers, and other resources on the same topics. That will give you an idea for how much learning you are in for and how long it will take you to get everything working. Good luck.

The end user requires Excel in this case. I think what I'll end up doing is saving everything in csv format while the test is underway and write it all into the Excel template when the test completes.

Gribo, martin_g and Yair, Thanks for the help. Indeed in the guts of the RGT's New Report.vi is a Visible property that allows you to run 'hidden' if you set it to False. One good and bad thing about it is that it just works for the file that you open with the RGT. Good because you don't have to reset it to True to use Excel once you are finished with it in LabVIEW. Bad because if you open any other Excel file, outside of LV, while you are using the 'hidden' one in LV, the hidden one is no longer hidden. I don't know if this will be enough security for this application (if an operator were to stumble through to the active Excel file and close it we could lose a couple days of test data), but it is good to know. Thanks again.

Gribo, Thanks for the reply, unfortunately I can't find an Excel .NET API from Microsoft. If I drop a .NET constructor node on my block diagram and go to select an assembly, the only Excel one I can find is Microsoft.Office.Interop.Excel and it's application object has no public items. I've tried searching the web for an Excel .NET API and can't find anything from Microsoft other than what I already have. I must be looking in the wrong places, can you point me in the right direction? Steve

I have an application that uses the report generation functions to write test data into an Excel file. I've set it up to open Excel minimized, but I'd like to run Excel in the background or 'hidden' so that the operator can't accidently close the file during the test run. Does anyone know how to do this?

lovemachinez, You don't need to close the previous port before you read from the next port. You should open all your ports, read from them in the For Loop as QueueYueue suggested, and then close all of them when you are finished. See attached example. multiport example LV2010.vi

Mark, I had a similar need to replace a PCI-1405 about a year ago and found a product called PixelPusher at eyetalksystems.com that connects through a USB port. It has some LabVIEW support. I was able to get it to work without too much trouble. Ultimately the project ended up going all digital so I never got beyond the demonstration stage with PixelPusher. Steve

rasmusvt, Your sample rate is being limited by your poll, read, and write code. Your loop will only run as fast as the slowest process, so your sampling rate control will only come into play if it is slower than the time it takes to poll your stepper, read your DAQ, and write to file. My guess is that polling your stepper is what is taking the most time, especially if you are polling over a simple serial connection. You might be able to speed that up some if you can increase your baud rate, but I'm just guessing here, and getting to 1000 S/s is probably not in the cards.

ZZZ, To allow the PAUSE button to stop the loop, you need to change the behavior of the RUN button event case so that it doesn't lock the front panel. Right click on the "RUN": Mouse Down event and select Edit Events Handled by this Case. Unselect the Lock Front Panel box at the lower left of the Edit Events window. With this selected (the default condition), the program won't process the PAUSE button press (or any other button press) until the loop stops. Steve

For the Data Base Connectivity toolkit and the Report Generation toolkit, you only need the standard LabVIEW run-time to run your exe.

I ran into some strange com port behavior and am hoping someone can offer some insight. I have three systems deployed that use USB to 485 converters to talk to stepper motor drives. Each system has three drives and converters, each converter installs as a Com port. I am using Com3, Com4, and Com5. LabVIEW writes commands to the ports to control the motor speeds. LabVIEW runs on a laptop and the converters are connected through a USB hub. System #2 started having lockup problems with the motor on Com3 -- the motor wouldn't respond. We replaced the converter and it has run fine for the last month. When the converter is phyically replaced, it installs a new Com port for it which I renamed to Com3. System #3 had problems as soon as we tried to start it up on the production floor, after working fine in the lab during integration. The problem presented the same as System #2 -- the Com3 motor wouldn't repond to commands. With both systems the 'lockup' would start (if it was going to happen) when we started the control program and you could sometimes clear it by doing a complete reboot (power cycle the motor drives and shutdown and restart the laptop). With System #3, I decided to dig a little deeper before just replacing the converter because we plan to deploy several more systems and we don't want to spend all our time chasing this issue. I inserted code to allow me to see the command being sent to each motor dirver and the driver response. Of course once I had the monitoring code in place, System #3 worked fine. Since the issue appeared at start up I started cycling the system. After about 8 power cycles the lockup reappeared and persisted through several more power cycles. The motors that were working (Com4 and Com5) showed the expected command and response. The response is an echo of the speed command with a linefeed and cursor character appended to the end. The Com3 motor showed a response with just the speed command echo (no linefeed and no cursor character) This is where it gets a little strange. I disconnected the cable at the motor drive end and Com3 showed the same response even though it was no longer connected. If I disconnected the Com4 or Com5 cable I would get no response at all. I disconnected the Com3 converter from the USB hub and it still showed the command echo. Now it gets stranger still. If I change the port name from Com3 to Com6 (no change in hardware, just rename the port in the code and in the Windows device manager), the motor works. To get the name change to take I have to do a complete reboot, so I wasn't sure if it was the name change or the reboot that 'fixed' things. I switched back and forth between Com3 and Com6 four times. Everytime the motor works with Com6 and doesn't work with Com3 (same false command echo with no cursor at the end). The manufacturer of the motor drives and converters hasn't seen this before and they suspect it has something to do with the Com3 in Windows (32bit Win7) or that maybe some other program is messing with Com3. The 'other program' theory is possible, but not likely in that the laptops were purchased new for this application and the only things installed have been LV2009, MAX, and the motor driver utilities. I don't think this laptop has even been online because I used LV2009 in evaluation mode only before installing the program as an exe. System #3 has been running fine for the last week using Com6, although that probably means it has only gone through 3 to 5 power ups. Has anyone seen anything like this? Is Com3 in some way different than Com4, Com5, or Com6? Any thoughts or insights are appreciated. Thanks, Steve

Mike, Thank you for the info on LV and multiple cores. It isn't entirely clear that this performance issue hasn't been around in the code for a while since this is the first time (or at least the first time anyone currently involved knows of) that we've looked this deep into what is happening with the code. And an extra thank you for reminding me to use the profiling window (it is under Project -> Show Profile Window in 5.0.1 also) -- one of those tools I tend to forget about. I will use it the next time I'm in the plant. Steve

Thanks for the reminder. It might be an issue if we end up bringing the code all the way up to current. Yes, this is apparently a somewhat recent development. When we reviewed the spares list a year ago we identified the 1410 as a drop in replacement. Per NI, you can still order a 1410, but you may not get it as they are having component supply issues.

The full system consists of: Stage 1 WinXP Pro 2002 SP2 with LV5 running on a Pentium 4 2.8GHz and 1GB RAM SCXI chassis with (1) 1163R relay card driving 22 solenoids/actuators, (2) 1162HV input cards reading 44 limit switches, and (1) 1122 reading a handful of thremocouples 18 serial ports Stage 2 (my details here are a little sketchy since we've been concentrating on Stage 1) WinXP running LV7.1 SCSI chassis with (1) 1163 relay card driving 15 solenoids/actuators, (1) 1162HV inpu card reading 30 limit switches, and (1) 1122 reading a handful of thermocouples PCI-IMAQ-1409 analog video board (now obsolete) VIdeo switch 9 video cameras Upgrading the PC is only being considered as an interim incremental fix for Stage 1 throughput. The whole system is in need of an overhaul as there have been many bells/whisles/warts added over the years by many different hands. The client has been reluctant to upgrade from 5 and 7.1 because they want to squeeze everything out of what they have and are afraid of the effort and risks of upgrading. We've just discovered that there are no drop in replacements for the video board in Stage 2, so we may be forced to upgrade that portion of the system. Right now we are trying to identify what we need to do to sustain and maintain the equipment going forward. And to answer your question, no it wouldn't necessarily be prohibitive to have someone come in and 'fix' the issue(s) -- but first we've got to figure out what the issues are.

Hi All, I've searched the LAVA archives and the NI website and haven't been able to find anything related to my issue, so I'm hoping someone here can provide some insight. I'm supporting a client who has a piece of production equipment that is controlled by LV5.0.1 in the development environment. As we've added functionality to the code it has started to bog down and that is impacting the production throughput. The code has been worked on by many people over the last decade and is sorely in need of a complete overhaul. The overhaul, if it happens, won't be quick so I'm am looking at what we can do in the short term to improve the situation. Does anyone have experience running LV5 on a mulicore processor? When LV5 was released, it was touted as "hyperthread capable", but that was before multicore processors entered the mainstream. Is LV5 capable of taking advantage of multiple cores, or will it just run on one of the cores? Our current PC configuration: Dell Workstation PWS370 Pentium 4, 2.8GHz, 1GB RAM WinXP Pro Version 2002, SP2 Does anyone have any experience to share? Thanks, Steve

I passed my CLD recert a few weeks back. For me, the most useful thing I did to prepare was taking the practice exams and studying the answers. If you understand the practice exam questions, you'll do fine on the recert. Good luck!