dterry

Good point! I suppose the benchmarks would then be more along the lines of "how fast can the server turn it around". I like the idea of event/change based updates as opposed to polling, but you are right that it will be very driver dependent. Honestly, I wish I could just get the data directly in LV. That way I can use the data as I need it now, and build my own data server when I have time! Any reason to go with the NI OPC Server over the Kepserver? Don't think I knew that ... wonder if it is true of RT as well. Not that I'm looking to dive into the SVE right now, but good knowledge to have anyways. Cool on the .net driver, if I go this route, I'll have to check it out. I'm assuming Linux RT == no .NET unless NI has worked out something fancy. Thanks for the other links, I'll check them out!

Well, looks like Google is better at this search thing than whatever platform LAVA runs on haha. Good to know on this, I already have a Modbus abstraction that works well, so this could save me a lot of time! I'll look into it further. This is enlightening. I haven't been able to try the connection with the PLC yet, but did try with OPC UA on cRIO, so that probably explains why I saw no issues with updates. That will be difficult to work around, since the PLC is governing a high speed motor that I will need to programmatically monitor and control Yea, it does have logging and alarming built in, as well as OPC UA (same API as LVRT), I just had bad experiences with it in the past and was hoping there was something better (or that it has gotten better in the past 5 years). Thanks for all of your input, definitely helps me get started!

Hello all, I recently was presented with the task of integrating a Mitsubishi PLC into our systems. After a good deal of googling, I think the best (maybe only) way to get the data out is going to be via OPC, thanks to their proprietary Melsoft protocol. If anyone else knows a better way, feel free to stop me here. Now, we are currently expanding our data generating capabilities (hence the PLC), and I have been thinking about rearchitecting the way we collect data from all over our facility to be more flexible. Since I may be required to use OPC anyways, I was considering using an OPC server to aggregate all of the facility data, and then redistribute to control rooms, historical logging, etc. To do this, we would need to integrate our cRIOs and operator PCs into the OPC environment as well. I don’t see OPC mentioned very often (in fact it returns 0 results on LAVAG), and a lot of the stuff I see these days seems to be more “roll your own” or lower level (raw TCP/UDP, 0MQ, Network Streams, Transport.lvlib etc.) rather than a monolithic abstracting bridge like OPC. Unfortunately, I won’t have time to roll my own in the near future, but LVRT supports supports OPC UA, so I could potentially integrate the cRIOs fairly easily. Unfortunately, I think I would have to use LabVIEW DSC (or datasockets...) to integrate the PCs. I would be very grateful if anyone has the experience to comment on the following or anything else related to using OPC. What are viable update rates for OPC tags? I will need at the very (very) least 250 ms update rates. Is OPC typically low latency (time from data generated to to client received)? Does anyone have a recommendation for a product (NI OPC, Kepware, etc.)? Is OPC still popular, or are there other options for data aggregation that would be better suited to a new application? What are the options for logging and alarming with OPC? What are the options for talking to OPC from LabVIEW? How robust are the OPC connections in regards to reconnecting if a wireless connection is temporarily lost? Thanks in advance!

ShaunR, It seems like the database you sent is encrypted. Is there a password? Right now, I get errors because the file path ("TM.3db-> 12345" + AppDir) seems to resolve to <Not a Path>. I replaced it with a hardcoded path, and got the "Enter Password" dialog. Taking a SWAG, I entered "12345", but it threw error 26 [file is encrypted or is not a database]. I found that the password dialog was being bypassed (see below), but it worked fine once I rewired it. From what I can tell, the schema you put together looks some like my E-R diagram above. It helped to be able to see it somewhat implemented, and I think I may end up going this route, and dealing with the consequences (enforcing names/types/values, complex queries, application side logic, etc.). Thanks a ton for your help with this! It has been very enlightening and helpful in narrowing my focus for configuration management!

Quick concept I wrote. Example Frequency Stepper.vi

I like the UI for sure. Still not sure on the schema (as referenced in the last post) but I'd like to see it in person to understand better. Trying to check it out, but the installer is throwing an error.

This does work, I have used it many times. Anecdotally, the main issue I have run into when flattening classes to string is getting the versions correct on both sides. If you have changed the class in one app but not another, you can get a 1403 error in certain cases (LabVIEW: Attempted to read flattened data of a LabVIEW class. The data is corrupt. LabVIEW could not interpret the data as any valid flattened LabVIEW class.). Some additional reading on the subject: LAVA Thread NI KB

That's fair. Developing new applications is really a balancing act between stable technology and staying relevant. Think of all those poor XP reliant applications after it got sunsetted!

Still scratching my head on these, does anyone have any feedback? From my own research, storing classes is kind of a cluster. It looks like the two main options could: Some combination of "Table for each class", "Table for each concrete implementation", or "One table with all possible child columns". This feels super un-extensible. One Table for Abstract or Parent Class, with another table for parameters in TEXT or BLOB format. OR Anybody have any experience or warnings about do this?

Sorry ShaunR, still not really understanding what you are asking for. Here are a few test files. Is there a place I can get a trial of the API you keep referencing? Slip Sweep x 2.crtest Ky Test.crtest Data Sample 1650.crtest

My guess is the green FB node wasn't necessary. I would remove it and use standard debugging techniques to with the problem. Do highlight execution and probes work in sim loops?

Fair warning: I haven't touched CD&Sim toolkit in 6 years, but I wanted to try to help out. I think your cycle is outlined by the blue arrows below. Have you tried adding a feedback node in the red box below? You may also need one in the green box, not sure. I don't have the CD&Sim toolkit, but my gut tells me this would at least fix the "Wire is a member of a cycle" errors. P.S. Feedback nodes are in the Structures palette.

I guess I just assumed the data could be reliably backed up, but that's probably a generous assumption. that sucks!

Ah good point on the triggers. Basically, prevent a user from ever doing an update or delete, and then add an action to update the old record's tF. One question regarding the INSERT trigger. Your where statement looks for an identical record with a null tF. Would that just be a record with the same identifier instead? Like you said, the gist is there, just curious about that line. Thanks!

Alright, lets try this. I included two DAQ config files, another CALC file with different calcs/values, a CRACT (actuator) file, a CRSTEER (steer profile), and a limits file (CRSAFE). That enough variety? HS AI.daq Barcode.daq Generic.crsteer Limits.crsafe Sled.calc Sled.cract