Tim_S

Bitwise is the part that makes that more challenging as you could use multiply and add for AND and OR otherwise. I wound up using spreadsheet string to array, converting to RPN, then parsing through. It's not fast nor strait forward. I'm certainly interested if someone has a better idea.

I'm sending an object between executables in LV 8.6.1. So far it also works in 2011. I haven't run into any issues besides versioning. Tim

Gah! Okay, that's a little embarrassing. I thought I had a sample of what was causing the issue I was seeing in my actual code. Okay, back to head scratching on the bug in my code.

It may not be the best way, depending on what you're trying to do, but I've stored an index to an array in a variant instead of the data. This wound up being efficient for me as I needed to store all instances of a piece of data, but only needed to access the latest until end of test.

I ran into a bug in LV 2011 with the List Folder primitive. A pattern with an underscore in it will return an empty array despite matches in the target directory. Here is a demonstration of the bug: List Folder.zip I contacted NI about the bug. There is a CAR for the MAC OS only at the moment and it will either be updated or a new CAR created. I wasn't able to get what version of LabVIEW will correct this. Tim

No control can be programmatically created in LabVIEW at runtime. Controls can be moved, resized, made visible, etc. What you're trying to do is challenging. The subpanels sounds promising. I'm not sure how feasible it is to drag them about as they do not natively have a title bar that windows do. Somewhere around is some code to make a VI a child window; that sounds more like what you're trying. I've never attempted to create a child window and not looked at the code, so I'm not sure how challenging that may be. Tim

You can't invert through the motherboard or BIOS. There is no setting LabVIEW can get to which will have the parallel port data bits go low instead of high on power up. I was referring to treating the output as inverted signal.

Data transfer would be bytes per second. Bytes would be number of U8s or length of string. Seconds would be the dt between reads. It's pretty trivial from there.

You don't; the pull-up resistors keep the level high until told otherwise. You invert the output instead.

That's a classic problem; [low cost] DIO cards have a tendency to set their outputs high when initialized by software. I've solved it previously by having one of the outputs go to a on after delay relay which turned on control power to the rest of the outputs. Not a great solution (relying on the problem to solve the problem), but we needed something cheap and immediate. EDIT: Hit post and realized you can have a switch that turns on "control power", which is power to anything that can move. The outputs of the parallel port can't drive much, so you'll need a transistor, relay or the like if you're driving something more than a LED.

What event are you using? Could it be the event is supposed to fire twice?

I completely agree. NI tech support is adding it to their database for when someone has the same issue. I expect Eaton and Delta (not sure who wrote the firmware for the ethernet module; Eaton repackages Delta PLCs) are not the only ones who are not aware of or compliant with the RFC standard. The other pieces of my system (Eaton/Vaccon drives, Festo manifolds, and Balluff RFID reader) have no issues.

Sorry, though I'd posted. Adding the TcpAckFrequency with data = 0x01 to the registry for the physical interface resolved it. The default value is 2, meaning it will acknowledge every other TCP message or after a 200 msec timeout (the PLC retransmitted after 50 msec). Setting the data to 1 forces it to acknowledge every message that arrives. I've passed the info along to NI. Interestingly, I had to use email support as I used the word "Modbus"; it seems there is a recon (I think that was the name) group responsible for such and they only support through email at the moment. I could have continued with phone support if I had stuck to the TCP aspect. Tim

You're looking for a tool rather than a dedicated system then. I just googled it to curious what they were offering. Can't say I've seen it before. There isn't much information, but it looks to compete with TestStand, which sells for $4000 for a development license, $530 for a deployment license.

I've not had the opportunity to use PXI and am not very familiar with it, but... It seems to me this is only important if you mix the two frequently. Assuming the speed claim is correct (can you reliably push 4 GB through traces in a real-world application? don't know), how big of a pipe do you need? It's nice to have a Formula1 engine under the hood, but if all you ever will use is a golf-cart worth... I'm curious about this one. We leave at least 1U around rack-mount PCs, PLCs, UPS, etc., to allow air flow to occur. The only way I can see to avoid this would be to have forced air flow in the case. Hrm... Is that the TestExec SL software? It doesn't look very free on the website. Then there is the adage of getting what you pay for...

This is pretty trivial. Check the array pallet.

Most of the gaming advice has been about removing unneeded services and setting the performance options (system properties->advanced tab->performance options button) to "adjust for best performance". These did not help the acknowledge issue. I found one YouTube video at: It recommends going into the registry and adding "TcpAckFrequency" and "TCPNoDelay" to the parameters for the NIC. I'm seeing a positive change, but I was fooled a couple of times today, so I'm not ready to say it's fixed yet. The registry path is: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces\{ .... some GUID identifying your NIC card port .... } Check the IP address to figure out which interface you should be looking at. Under the path add the values: TcpAckFrequency DWORD data=0x1 TCPNoDelay DWORD data=0x1 TCPNoDelay = 1 turns off nagling TcpAckFrequency is far more interesting per: http://support.microsoft.com/kb/328890 It seems Windows sends out a TCP acknowledge for every other segment received (per RFC 1122). Setting the ack frequency from 2 (default of every other segment) to 1 will acknowledge every segment. Tim

So long as you have the storage space for it. My typical database is terabytes in size, mainly because the customer (lately) has wanted to see 1-2 years of production online (7-50 years offline, depending on the customer). Space becomes a premium when the customer wants to marry production data in with the test data. A single part's record can get to 3-5 MB as flat-file.

Before I forget, I appreciate any and all thoughts. Sorry, forgot to put that in. Windows7 is the OS. It is possible that I'm seeing an OS level issue, which appears to be how the person solved the issue (replace with WinXP system). I don't have a reset of the ethernet card and am starting the PC side after the PLC has booted up. I'll check for the start of connection, though. Ah, yes, that's it. Unfortunately it's not the cause. TCP is a connection based protocol, meaning all messages have to be acknowledged by the receiver; this occurs down in the TCP primitives. The issue I'm having doesn't show up except that the TCP Read takes ~56 msec to complete. The TCP Read should complete in ~6 msec if the TCP acknowledge by the PC occurred as it should instead of occurring when the PLC retransmits the message after not receiving an acknowledgement.

I've been scratching my head with this one and am hoping someone has dealt with it before. My physical setup is a PC, CAT5 cables, a couple of switches, an Eaton HMI, and an Eaton PLC. I'm talking Modbus TCP to the PLC using the library on NI's website. I'm using Wireshark to troubleshoot other problems and found the PLC retransmitting the response to the PC very frequently (not every time). The PC is reads and writes 32 words to the PLC every 100 msec, but only performs a write when the data changes. The PLC transmits a response within 6 msec of a read message (function 3 in Modbus). The PC never responds with an acknowledgement of the message from the PLC. The PLC retransmits 50 msec later and the PC acknowledges that message. The write messages occur about every 1 second (my heartbeat to the PLC). I've tried switching to the second port on the PC, which goes to a second card in the PLC. That network has four drives, two air manifolds, a remote I/O block and an RFID system on it that are all talking to the PLC. The PLC sequences through all the remote devices, including the PC, so the response to the PC can take 75 - 150+ msec. The PC always acknowledges the first message with that network. Anyone have some thoughts as to what's going on? Tim Forgot to mention that I'm using LabVIEW 8.6.1 and have swapped all of the network components.

Manuals are your friends. They will tell you how the physical hookup goes. The software part will depend on the physical connection and the commands (also in the manual!). Check the manufacturer's website for (example) code to communicate with their device. Go through the LabVIEW example programs that install with LabVIEW to see how to do tasks; you'll have to put together multiple things to get what you need. Tim

I've not used either one, however our field support bought a NI PCMCIA digitizer card some years back and have been pretty happy with it.

You may have luck by opening just the class and editing it by itself (no project open). Having as little as possible open seems to help LabVIEW not get into some infinite loop. Tim

Yea, I've had similar problems. It's been to where I had to open the "offending" VIs outside of the project, correct the issue and save before I could load the project without Bad Stuff happening. Tim

First, don't trust the PC to read data every 5 msec; that's just too fast for a Windows based system. Yes, Windows can do it, but all it takes is someone opening a large file to mess up your data acquisition. You're better off with 1 kHz sample rate and 100 sample read (read every tenth of a second). Second, is the DAQ the only thing in the system? Is there anything that is creating a time delay? Event structure? Wait? Wait until multiple? It's possible that you are not reading the data fast enough simply because you're not getting around to it in time. Third, people can help far more readily you if you post the code you're working with. If it's too big, make a small example that demonstrates the issue. Tim