Tim_S

Having a limited budget (read as none), I appreciate free stuff. Free stuff is great when it works. I use Clonezilla for imaging systems as I got tired of paying for Acronis or Ghost (they are licensed per machine when you buy one copy at a time). When it doesn't work there is no one to call. NI has a team of experts that they make accessible. That's no small thing and the "young kids" are going to learn the hard way. Last I heard NI reps around here have convinced at least one global-level group at a Big-Three automotive the best option for a test stand control module is not a custom program in a control module (it takes forever to convince the programming team to put in the flags to bypass things for testing) but a cRIO. I've seen stands with a dozen control modules in them switched out with relays to handle model changes over the years.

From what I'm seeing working for a supplier to the automotive industry, the population of engineers is mostly "grey-haired old folks". That's in the supplier and customer side. There is a massive wealth of knowledge and experience that has started to retire. Python has its strong points. Collecting and analyzing data, or time to market for custom test equipment isn't among them. These are LabVIEW's strengths because that's what the language was designed around.

LabVIEW does not ship with Modbus communication. That feature is part of the Data Supervisory and Control module (DSC). There is the Plasmionique Modbus Master in the download section that may do what you're needing (I've not used it) and the NI Modbus code on the NI website.

I've got to parrot hooovahh's comment, though I think yours look like smartphone/tablet controls that all behave similarly. I've used the radio buttons with two round LEDs with good success for true/false selection; one LED was darker blue (false) and the other was lighter yellow (true). Back a lifetime ago I worked with a system that had that setup for colorblindness and quick response (use was due to military study leading to a specification). The NI buttons look the same in true/false state when you view them in grayscale; yours appear different, so would be usable by those colorblind.

Hrm... This resembles a linked list to me.

Performing a TCP read on a closed connection produces error code 66.

Don't expect you'll find something to write Q-DAS format. We had a package that output Q-DAS format from a database. It required training from Q-DAS, development of code by certified person, testing and approval of output by Q-DAS, sacrifice of firstborn son under the second full moon of the third month... It was a rather involved (and expensive) process. That's been some years and things may have improved since then. We didn't keep up the certification as we had only one customer in the automotive industry that uses Q-DAS and we've not been doing much businesses with that customer lately. (Most all our other customer seem to use Minitab or SQL/stored procedures for their statistics.)

My development cycle is quite long (years), so starting now means I'll be ready. Putting anything Linux on a plant floor would be interesting. I've recently had to explain to one plant's IT that it is a VERY-Bad-Idea (TM) to perform Windows updates during production and that was why the test stand incorrectly failed dozens of parts then rebooted.

Great. So the only way to prevent a test stand from going down due to a Windows update reboot is to create a completely isolated network. That does not bode well for remote equipment support and fast response to issues. Time to escalate plans to shift the actual testing portion into PXI/cRIO and make the Windows PC storage and HMI.

My understanding is there is corporate versions that do not or can be set to not update automatically. This may not be the stock Dell computer, though.

I've been using Sorenson power supplies. They aren't as good as they used to be. My issues with them are with the RS232 communication when the PC tries to reconnect (nothing seems to work requiring shutting down the program, power cycling the Sorenson, and then bringing the program back up). Otherwise they haven't given me problems for my application. We've been using them to supply power to electronic control modules (ECM) and vehicle sensors. The ECMs can have a huge inrush to where we put in a marine battery with trickle charger in the system to act like a battery backup. For LabVIEW communication, it's just well documented SCPI commands over serial for what I've been using.

OK, I see where there are improvements; the link is appreciated. I was trying to figure out if the protocol could still be going through low-priority layers or have other delays and found a Wiki article that provides general overview of the protocol. The use of TCP as an option would address the issues I've had with OPC.

I'm not sure what you're trying to do, but some commentary on OPC... OPC is great until you want to do something that requires timing of faster than, oh, 30 seconds.OLE (OPC = OLE for Process Control) runs at the lowest priority possible in Windows. As such, anything and everything can keep OPC communication from occurring. I personally have had communication go dead for about 10 seconds on multiple test stands using RSLinx, Siemens Profibus card (has OPC server) and Kepware. OPC is best used when notification of an event is not time critical such as a light indicating motor on status at the other end of a building.

This isn't so much a question of how to do this in LabVIEW as how to do this with the hardware you have. Are you using NI data acquisition cards? If so, then there is a way to bring the encoder in as a start scan trigger and there are examples that ship with LabVIEW on how to use an external clock with a data acquisition. You've not listed what data acquisition hardware you're using, so it's hard to provide more information.

That depends on the project. Some projects are full assembly lines where the conveyor, assembly and gauging stations are controlled by PLCs and the more advanced testing is done by PLC motion control and PC performing supervisory test control, data collection and analysis, etc. Small single test stations may only have a PC running the entire show (including motion control). There might be 100% LabVIEW or 100% PLC depending on the project (particularly since we may include other companys' software instead of our LabVIEW-based solution at customer requirement). Our original LabVIEW application was written back in LabVIEW 2 when having the PLC do the bulk of things and the PC providing direction and acquiring/analyzing was pushing what could be done (this was also back in the days where you had to make your own custom cards as there just wasn't an off-the-shelf anything). We were still using a decedent of that software when I came on board (including a lot of things you had to do in LabVIEW 2 just to get things to work). That software is long mothballed and we're on version 4.2 of the current software, which is a set of distributed applications (security, data acquisition, error display, calibration, sequencing...) that communicate through TCP and shared variables. Our thought is to migrate the test itself out of the Windows PC into a real-time operating system and use the Windows PC for HMI and mid-term storage. We were able to get as far as we have with this because of posts people made on LavaG that we learned from and were able to get a lot of help from people here. (NI tech support is great, but I had to spend a lot of time explaining the concept of a plugin to them from LabVIEW 8.0 to LabVIEW 2012).

Yea, the lack of information and the lack of recognition are getting my attention. Our systems have a plethora of drives, pneumatics, hydraulics... lots of motion control and contiguous fault monitoring. Lots of assembly stations where a small PLC works fine (or a larger one running a bunch of stations). The plants we put systems in have plenty of maintenance people who can deal with PLCs and they are comfortable with them. The test stations we put in are often the most advanced piece of hardware they have in the plant.

Our IT department is rolling out a SCC package called Version Dog to our site. Looking a the website, it looks to be geared for PLCs but down in the documentation it mentions LabVIEW. Has anyone heard of this before? Used it? Have opinions on it? Not impressed by the amount of openly available non-fluff information on the website. We do have a SVN server running, however the network changes from when the current owners took over have FUBAR our ability to connect to SVN from our desk. This appears to be a much needed effort to version control the PLC programs (long overdue) and an attempt to close out IT work tickets that are many years old. Thanks in advance for any replies.

The cursors on the chart/graph/xy plot controls go to the extents.To get a line like in your pictures you would have to do something like a picture control underneath a graph with a clear background. The cursor line would be on the picture control. There would be a bit of math to draw the line and events to keep the two synchronized. Tim

Yes, that's the one I was referring to. Specifically, the part that relates: This issue can be caused because some third party devices do not implement all serial settings on their USB-Serial adapters. To avoid the problem, do not use the VISA Configure Serial Port VI in your program. Instead use a VISA property node to set only the supported properties. To determine which properties are unsupported by your USB-Serial adapter, use a VISA property node, and set the properties one at a time to see which properties cause the I/O error to be thrown. The error message is all about serial. I looked in the Modbus serial init and saw all the properties being set. Try just setting one at a time to see what is throwing the error.

The articles you linked to indicate this is a serial error (versus a Modbus error). It looks like the you may need to modify the Modbus serial initialization VI to work with your device.

I recently had a... let's call it a a conversation... with a customer who was insistent the system would work perfectly for 10 years. The only way I know to do this is to provide double-redundant systems and perform a level of testing that takes months to perform. None of my customers are going to want the extra price tag that goes along with the redundancy or testing. If my customer base was from, oh, medical or nuclear power... now that's a different story; then I would be contractually required to perform tests on all sorts of specifications (the IEEE ones on software are good for insomnia) and there would be a budget and a reason to do so.

I like that implementation. I took the first paragraph of text from NI's LabVIEW webpage (115 words) and put it in to a comparison of 10,000 iterations on a fresh load of LabVIEW. bmoyer's algorithm: 15,028 msec Tim_S's algorithm: 15,365 msec Then I went tried again with the text "I'm a test": bmoyer's algorithm: 4,688 msec Tim_S's algorithm: 617 msec I added more text from the same webpage for 284 words and wound up with: bmoyer's algorithm: 28,519 msec Tim_S's algorithm: 38,095 msec

I was working on a user interface and needed to put text in a button. I realized I needed to word wrap the text and couldn't find a VI that already does that. The generic algorithm seems to combine words together and put in line feeds when the length is exceeded. Based on that I put together the attached (please pardon the dust). Then I started wondering if there was a better way. Any thoughts? Tim Format for word wrap.vi

I haven't worked with LabPython. From the release information here it indicates that LabPython was tested with Python v2.5. Don't know if that makes a difference.

I have a CSV file for the measurements and a TDMS file for the waveforms. The portion of my code that saves the test record is a plugin, so the file format of the record can be altered fairly easily.