Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


dterry last won the day on May 2 2017

dterry had the most liked content!

Community Reputation


About dterry

  • Rank
    More Active
  • Birthday April 7

Profile Information

  • Gender
    Not Telling

LabVIEW Information

  • Version
    LabVIEW 2015
  • Since

Recent Profile Visitors

1,357 profile views
  1. 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 k
  2. 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 lo
  3. 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 O
  4. 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
  5. Quick concept I wrote. Example Frequency Stepper.vi
  6. 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.
  7. 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
  8. 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!
  9. 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?
  10. 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
  11. 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?
  12. 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.
  13. I guess I just assumed the data could be reliably backed up, but that's probably a generous assumption. that sucks!
  14. 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!
  15. 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
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.