Jump to content

Tim_S

Members
  • Posts

    873
  • Joined

  • Last visited

  • Days Won

    17

Everything posted by Tim_S

  1. I believe Mitsubishi PLCs also talk Modbus. There is a big difference between OPC and OPC UA (this was pointed out to be on these forms, so I know there is at least one entry). I've yet to look up the difference. I am familiar with OPC, so my comments relate to that save where noted. There is a shipping example with LabVIEW on OPC using datasocket. I recommend sending a data block instead of individual tags, particularly if you have a lot data. There is overhead with each tag that can be problematic. Down side to a data block is having to parse out the information you're interested in. Meeting your update rate could be problematic. OPC is meant for process control (the acronym is "OLE for Process Control"). OPC goes through OLE which has the lowest priority Windows can assign. Anything with normal or high priority can block the OPC communication for 10s of seconds. OPC UA does not do this, so doesn't have the issue. I've used KepWare before and have had nothing but good experience with it. I did have to break up a data block into multiple once it reached somewhere around 128 bytes as communication stopped above that limit. I expect that's an OPC spec rather than a KepWare limitation. Don't know if KepWare can do OPC UA. I expect OPC isn't as mentioned as PROFINET and Ethernet/IP have become more dominant. It still has its applications. For logging and alarming, I believe LabVIEW DSC has that built in otherwise you have to make your own. I believe DSC can do OPC UA. I've never tried wireless, so can't fully answer about that one. I have had ethernet cables unplugged and PLCs taken out of run mode, and always had good recovery with that.
  2. There's a bunch of ways to create a common storage point... functional globals, global variables, single-element queues, data value references... each one has it's pluses and minuses. A lot of what people use depends on personal preference. You can use a normal VI as a functional global in a cloned VI. The reentrant setting only applies to the VI it is set in (in this case the one you are cloning). All of the subVIs have their own execution state. I'm not clear on your item (2). It sounds like you're thinking of a single element queue, but there isn't a separate VI involved in that.
  3. There is a whole subpallet labeled "Filters" under Signal Processing that are applicable, and that's really only a subset of what is out in the world. To know which filter(s) you want to use, you need to identify what you want to get rid of first. Not all filters are equal. Some maintain amplitude, but shift phase. Others are designed to maintain phase at the cost of amplitude. Each one has its use. So the method to solve the problem is to identify what you want to keep and what you want to filter out, then select one or more filters that do that. If you want some assistance in picking filters, then you're going to have to provide some additional information about your raw data.
  4. The class.ctl not present in the packed library is expected. I don't have a reason for this, though the packed library is compiled code, so the private data (the class.ctl) is no longer visible. If you compiled the packed library with Enable Debug flag turned on then I would expect to be able to probe the value (can't say I've payed attention to that). I expect the needed information is stripped out otherwise.
  5. Laptops and industrial PCs are all computers. Atom processors are low-end processors. I expect you have something much faster in your laptop and likely a lot more memory. You're best bet is to use your laptop specs as the requirements for an industrial PC. To give you a better answer we'd have to know what your application is, your program architecture, performance requirements... There isn't a better for operating system (unless you're talking something like Windows Me and Vista, but those were just bad in general). There will be differences, but not better. Windows 7 has hit end of support (see Windows Lifecycle sheet) and end of sales (see article). Win7 will be available on industrial computers for some time, but not long term. If you are looking at something that needs to have components available for a decade, I'd go Win10.
  6. Searching for the message on NI's website gives you a lot of hits including a better description of what the message means. Connecting an output to an input breaks LabVIEW code. Putting feedback nodes and shift registers in allows you to fix the where the code is broken.
  7. So what are the messages? Just occurred to me that you have a simulation with no feedback nodes or shift registers. Both are used to send values from one instance of a loop to the next. Without the messages, I would guess your problem is the compiler is trying to find someplace to start and is looping back on itself.
  8. There's been a couple of threads on this in the last year-or-so. You may want to try searching for those.
  9. A broken wire is like a syntax error in a text-based language; you have coded something that is not valid. This is not to say you've implemented the formula correctly, but something you've coded does not meet the language requirements. It's like "Jane walks" is a valid sentence (noun and verb), but "Jane Billy" is not (noun and noun). If you select View->Error List then a window will appear providing the reason the wires are broken.
  10. Hrm... It looks almost like there is a threshold on the second image. I'm wondering if you have the same lighting and camera settings? Lighting has been the bane of many vision systems.
  11. If you look through the various pallets, there is a Array Max & Min primitive.
  12. The data value reference (DVR) is a pointer to the data (in your case an object). Entering the in place element (IPE) structure using the data value read/write puts a lock on the reference to ensure no one else tries to modify the data. This blocks any other code from using the DVR. So the only way for other code to access the data is to write back to the DVR when leaving the IPE. The only way to use a DVR in the way you are trying is to only access it at the moment you need to, which is not what you are doing. There is a significant time-cost of locking/unlocking the DVR that can make this a very undesirable way to use it. There are other means to access singleton data in multiple locations. There are action engines, single element queues, global variables... All have their pluses and minuses. However, is keeping the data by-value needed for your application? The compiler is pretty good about optimizing code to reduce data copies (there are good articles on how to improve memory performance on NI's website).
  13. I don't have LV2016 to open the file. What font are you using? You can get that behavior if you are not using a font that supports unicode.
  14. Wat you are describing is the concept of an integral. Rather than sum up a large rectangle (which you don't have), you break up the object into little rectangles and sum those up.
  15. The NI code seems to use the convention of having a Canceled output. Seems that following the same convention would have less confusion. (From a practical standpoint, that is.)
  16. OK, I understand what you're doing better now. I have multiple applications using the same base objects as well. My solution was to have a common subdirectory for the base PPLs from where all the applications are installed. For example, the applications would install in: C:\Program Files\My Company\ and the PPLs are in: C:\Program Files\My Company\Plugins\ The configuration and dynamically loaded files are in the common application directory, so reside under: C:\ProgramData\My Company\ This generally follows Windows application layout. The files that would regularly change (configuration, project-specific plugins) do not require special or elevated permissions, so UAC is not an issue. NI's installer is able to handle this without too much work, so life is good. Looking back, one thing I would probably have done differently is each application would be in a subdirectory and the PPLs in an adjacent "Common" or "Shared" subdirectory.
  17. There is a means to dynamically load a PPL, but probably not the way you are using it. I expect you've dropped VIs/classes from the PPL right onto your block diagram. If you are using classes, then you would need to have a parent class built into a PPL that both the application and the dynamically loaded child object use. The parent object gets used throughout the application code and the child object gets loaded at run time. If you are using VIs, then you use it like any other VI with VI server.
  18. Tim_S

    Wait. What?

    I expect there will be many people trying to sign up in July. While it has been many years since I was able to attend NI Week, I still recall the display at the bank showing 99 degrees and 100% RH at 7am. It was an interesting experience stepping out of the hotel, sweating during the two block walk to the convention, then having all that sweat instantly freeze upon entering the convention hotel.
  19. I've not used a ethernet/serial adapter before. Does the driver create a virtual COM port on the PC?
  20. Do you have anything indicating how much of a speed difference there is?
  21. You should swap the two frames so that you measure the first iteration correctly, but otherwise don't see anything wrong with how you're measuring the loop execution time. How much increase is occurring? Your insert and select are in parallel to each other, so there is nothing forcing one to execute first. Is that by intent?
  22. Tim_S

    Turn Key DAS

    The LMS SCADAS page looks to be only hardware. The connectors on the hardware are nice as not all of the C series cards have that (usually terminals or D-sub for the ones I use). There is mention of synchronizing with CAN and video; I've not tried that with cDAQ, so not sure how easy. Up in the LMS Testing Solutions are some software screenshots, presumably software that works with the LMS SCADAS hardware. These look like pretty basic screens one would use for the applications. There is mention of a networked central data repository, but no indication of how to access the data. There's very little information quickly available. I'm seeing a system that has a bunch of canned packages that you can use with it. If you live within the canned packages, then this will likely work well. It has a lot of features that make it attractive (immediately checking data via bluetooth, central data repository...). I expect the down sides to this system are the ability to step outside the confines of it and the cost. NI prices aren't cheap, so system cost may be comparable. At the same time, I've never seen Siemens give anything away that doesn't directly lead to buying more Siemens stuff.
  23. I'm using JSON for application configuration, and serialization for version updating.
  24. Isn't that standard operating procedure to do that four or five times?
×
×
  • Create New...

Important Information

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