pallen

Again, this may or may not be an actual "bug". But according to the AE I spoke with at NI, it is a condition that has occurred for others as well. One of my current projects has a large number of configured Tasks in MAX. (Over 100) Occasionally when I've tried to make changes to a channel, I'm unable to save the change due to an unknown error. Once this error occurred, even changing the channel back to its original configuration would not work. Any attempt to save resulted in an error that listed nothing as it's "Possible Reasons". Unfortunately I don't have the error number that was generated. But a search for it only turned up posts by others that couldn't figure out what the error was. Even the NI AE had no idea. The only work around I found was to delete the channel completely and shutdown MAX. Then, re-open and re-create the channel. It was not possible to re-create a channel of the same name without first closing MAX. This occurred on a PXI-8196 with LV 7.1 and DAQ 8

This might not even be a "bug". But it's unusual behavior I've just started to notice on my current project. I'm using constants to supply a VISA resource name in my code. This gives me a little drop down box from which I can select COM1, COM3, or LPT1. For some reason all my drop down boxes keep graying out occasionally. But they restore on a reboot. The code still works alright, and the port isn't being held open or anything. I'm just wondering what the problem might be.

Thanks very much for your work on this Ben. As a new user to LV, I'm always running into (and hopefully overcoming) obstacles. It really makes things much easier when you know a problem isn't one caused by your own code.

You should be able to. Your avatar name suggests that you might be running LabView in Linux, and this might make things a little more difficult. I do have sound working on my LV 7.0 installation using a modified Mandrake 9.2 distribution. But I've found that sound does not work as "well" yet for me as it does running on Win XP. If you open up the "Find Examples" application in your Help menu, you'll find a number "sound" examples. The very first one that lists on my Example Finder is "Record Wave File.vi". I do know this VI works with my microphone input in both Windows and Linux. But I have not tried it with the Line In input. (My laptop here does not have a Line In) Good luck.

I had similar problems with a USB6008. You can do a multichannel recording relatively easily if you setup a multichannel task in NIMAX. For my application I created a task that takes 2000 samples at 1K/sec on all four of the 6008's available analog channels. If you need some guidance on how to create a task in MAX, just ask.

Hello Kahlid, Thanks very much for your reply. The NI tech I've been working with also suggested using PortMon as a tool to help find the culprit. While I can't say for sure it's done that, it has done something rather interesting. If I reset my IAI controller and send my first serial command with PortMon running in Local Capture mode, the command goes through. Not only that; but once the first command is accepted and returns a reply, all other communication works as expected with or without PortMon running. I can even reset the controller. Quit LabView. Pretty much anything except reboot. If I reboot, I must start PortMon and reset the controller before sending the first command. Once communication is established, Hyperterminal works fine as well. Another recent (and very happy) discovery is that a USB to Serial converter is working just fine without having to jump through any hoops. As long as this solution continues to work, it's how we'll be going. But it still leaves me wondering why the included COM port was acting so weird. Obviously there's something going on here that may have effected other developers in the past. Oh well. At least it's working now.

I still think it was cool looking.

My current main project has run into a major stumbling block with the arrival of the target hardware. A critical part of this application requires serial communication between the PXI controller running Win XP SP2 and an IAI RCP2 Series controller. The serial communication side of this project was started before the arrival of our PXI hardware. The code was working well on a PC with Windows 2000 and LV 7.1 However when the same code was executed on the PXI hardware, there was no response from the IAI controller. The problem was all the more unusual because the software supplied by IAI *is* able to connect on the PXI hardware. Although it does appear to take much longer to establish the connection. Hyperterminal also appears to have problems on the PXI hardware. A text file that has an expected response gets none. But testing on both Win 2000 and XP SP2 machines verifies that there should be a response. I double checked the COM driver on the XP machine, and it's the same one the PXI is using. The firewall has been disabled. As have automatic updates. No anti-virus software has been installed. What really has me baffled is how IAI's software can connect, but apparently nothing else can. Every setting I can think to check is identical between this system and one that works. I even tried turning down the FIFO buffers on the COM port to see if that would help. I've sent NI Spy files to NI Tech Support. But the potential severity of this problem means I need to keep working on it until I find a solution. I'm hoping there's just something I'm overlooking. But I've run out of ideas. :headbang: Any ideas or thoughts on this one are greatly appreciated.

I noticed a lot of broken links as well. This link (http://www.intelligentactuator.com/) appears to be for the same company. But has fewer broken links. After a call to their Chicago office, I managed to figure out what I was doing wrong. I wasn't sending the control codes (STX and ETX) correctly. I ended up having to look up how to do this in LabView. At least I'm able to send a simple status request now. But it looks like I've got a whole lot of reading to do before I'll be close to what we want to do with them.

Season's Greetings LabView peoples, I'm just curious if anyone else has worked with these Robocylinders from IAI. http://www.robocylinder.com/products/actuators/default.asp We've just started using them ourselves, and I'm still in the "figuring things out" stage. They can be controlled both digitally and serially. I've already got digital controls working. But for my particular application I need both digital and serial. Quickly trying the examples in the manual using the Basic Serial LV example resulted in no response from the controller at all. I ran a sniffer to see what the proprietary control program was sending back and forth to the controller and it didn't look much like what printed in the manual. I've still got a lot of reading to do. But I was just curious if anyone had already worked with them.

Thanks for that info. The low impedance might cause some problems here as I'm measuring from an amplifier connected to film type pressure sensor. I'm not certain yet. But I believe I was seeing a much higher signal to noise ratio than I had on the original hardware. 1000 samples over one second on two channels is the most I need to ask from this system. Although I do need to monitor that digital input while this acquisition is happening. We did read the specs before we bought the unit, and it appeared to be capable of the job. But there have been a few "weird" things I've noticed since I started with them. The most annoying was not being able to close an opto relay with a digital output in the way we always have. I wouldn't think much current would be required for that. But apparently it was too much. The only way around it was to follow the "open drain" example in the documentation and essentially wire things "backwards". Tomorrow night I'll have some time to play with this system again. If I can't find a solution, I'll at least try to better document my failure. ...that sounds like a quote!

Thanks for the suggestions Alan. This is the first time I've worked with USB DAQ devices. Originally we were using a PCMCIA 6024E card for this project. But we switched to USB to save $$. But if we're going to run into problems with different target PCs it would be better to find out about it now rather than later. Unfortunately the laptop I use for development has limited driver support and I have noticed stability problems before with USB webcams. It bothers me a little to hear that USB hubs can be a problem. We'd hoped to package USB key or alternative storage device for data storage or perhaps even to house the executable code itself. I need to take a closer look at exactly how I'm building my state machine too I think. But switching that one input to analog shouldn't be too much of a problem if it's necessary. Thanks for the reply.

You can also just drag and drop image files from Windows Explorer onto your front panel.

Thanks for the reply. The DAQ hardware is a USB 6008. It appears to be LabView itself crashing. Windows shuts it down and asks if I want to send a "report" to MS. I haven't tried highlighting the execution yet. But because of the way things are timed in this application, it wouldn't be an entirely accurate picture of what's happening when the code is running at full speed. Definitely part of my troubleshooting plan though. The trigger itself is working. Its been verified in MAX as well as code snippets. The acquisition of the two channels simultaneously works fine in that state without the digital input there. I've been thinking about how I might monitor the digital input in another while loop if I have to. I was just wondering if there was something fundamentally wrong with what I was doing in the code. The documentation doesn't seem to say so. But I thought I'd ask around.

Hello fellow wire workers. I've got a bit of a problem DAQmx...at least I think that's what it is. I can't tell for sure because LabView is crashing completely when I get to the State that's in the picture. Is this because I've got two tasks running essentially at the same time? This was a problem with my analog acquisition at first. Then I configured a task to acquire on two channels and just split the data afterwards. Unfortunately I don't see a way of adding a digital input to an analog task. If I can't include the digital input in this state, I'm not really sure how else I can capture the trigger.

Sorry to hear about your lost post. I appreciate you taking the time to re-post after that. I can recall similar times when I've lost large amounts typing time, then being too frustrated to bother re-doing it. A result of this happening to me on more than one occasion has me now using a "compose" window in Thunderbird for nearly all my text writing. Sorry for leaving out details in my last reply. The files are indeed similarly named and each "pair" of files has the same number of elements in it. (I've included a sample this time for anyone interested) Thanks for attaching some code. It's always interesting to see how others (especially those with more experience than myself) approach a Labview program. For some reason your VI only seems to be catching the first elements of the last "set" of files it reads. Perhaps I'm just missing something. In any case, it's given me much food for thought. Thanks. Download File:post-247-1131038486.zip

Actually, when I wrote SDK I meant NI's State Diagram Toolkit. There is a command that I can send to the hardware that will return the number of available buffer slots. I could monitor this to ensure that over fill the buffer. I was just going to try to get things working with a timer first, then modify if needed. My state machine was working well, until I tried to start sending points from the second "set" of text files. For some reason I couldn't quite get that working, so I thought I'd try a different approach.

Thanks for the reply. I didn't include the section of code where I concatenate the results and add various commands because that part of things is pretty straightforward and working well. The reason I've got the timers in there is that the X and Y data is being passed to hardware with a limited buffer size. The timers control the rate the data is being passed and this prevents the buffer from over flowing. I am using the SDK (love it!) and did initially start off trying things that way. But I was hoping I could put the whole process into a neat little subVI.

I'm probably overlooking something here. But I've tried this one a bunch of different ways and still can't quite get what I need. I have a directory that contains a number of text files. Each text file is a single column of numbers. Some text files have an "X" in their name. Others have a "Y". What I'm trying to do is pull the first row out of an "X" file and concatenate it with the first row out of a "Y" file. Output a concatenated string. Wait some time. Then get the next row of both "X" and "Y". Repeat until all points have been "sent". I've tried this a number of different ways and keep running into stumbling blocks. Today I started looking at auto indexing For Loops. I'm pretty sure this is what I'm looking for. But I can't figure out how to make a subVI out of this mess and still be able to get a live "feed" from it. Any ideas greatly appreciated. Download File:post-247-1130971162.vi

I tend to start off with the default theme. Then add a little "flare" once I've got the core of the code working the way I want it. I've only delivered a few completed projects since I started with LV. But one of things I like to do is grab stuff from the customer's web site. (if they have one) Gimp is a great (free) tool for reworking things like logos and borders etc. I've not reworked any controls or displays yet. Although I did quite a bit of that when I was using Visual Designer. LV's default set is so much prettier than what I was used to, that I probably won't feel the need to "tweak" for quite some time.

This is probably an easy one. But I'm not sure if I'm missing something. One of the tools our company purchased recently was the State Diagram Toolkit. For the type of programing we've been doing, this a nice, simple tool that I've found very useful. On most of my applications, I end up adding a "Wait" or "Wait Until Next Multiple" in my main loop. Usually just 10ms or so. I'm doing this with the intention of freeing up a little CPU time when operations aren't time critical. But being fairly new to the whole LabView environment, I'm concerned I may be committing a faux pas or be guilty of employing bad technique. (No point in developing bad habits if I can avoid it) There are some "States" in my current project where I'd like the code to process as quickly as possible. (Re-sizing and saving images) But I notice poor front panel performance (lagging mouse and keyboard etc.) when there is no "Wait" function in my main loop. My question is; Am I asking for trouble by doing this? Is there a better way? Thanks.

Not yet. Should I be keeping my eyes out for one?

I've just started to play with 7.0 for Linux. The only problem I've had so far is the Example Finder doesn't seem to have any examples in it (But they're easy enough to find manually) and Firefox occasionally crashes when I'm viewing Help pages. A Search causes a crash every time. Today I made a very simple .exe in Linux and tried running it on a Windows box. A command window came up with an error and the program would not run. That was only my first try though. I have also opened VIs in Linux that were written in Windows. A few things that wouldn't cross over. But I think that was due more to version conflict. (7.0 Linux vs 7.1 Windows)

You may have tried this already; Have a look around for a GPL'd command line utility that you can call with arguments. My first google hit this page: http://www.icewalkers.com/search.php?q=cd%20burning A few goodies in there. Good luck.

Here's one that's got me scratching my head; I'm using the TCP Communicator-Active.vi from the examples to trigger an inspection on a DVT camera. In Windows, this works just fine. In Linux, it doesn't work at all. (for me.....yet) //Cut the rest of the post here after I figured out the problem. Windows was adding Carriage return where Linux wasn't. I can't believe it took me this long to figure that one out, considering I actually remember reading something about this one in a book recently. D'oh! :headbang: On the plus side, It's working. ...that reminds me; I saw a "W00T" license plate on a car on the 407 today.