Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by smithd

  1. I guess I would say look for the module being compatible with a 9074 in FPGA mode. This excludes things like the XNet interface which is RT-only but includes things like the raw CAN card. You can also emulate it in the project -- if the FPGA compiles, it will likely work. The two big showstoppers I've seen with ecat are... Yeah lots of small logic bits will save you with the ethercat...but theres also the risk you run out of space since the FPGA on those guys is so small. The other concern is the number of user-defined variables. While you can have full chassis worth of IO, you ca
  2. Tried to clarify above but I see your point.
  3. Theres some interesting additions -- I like the built-in sorting and filtering idea -- but one thing I can't get past, and its the issue with every error improvement I've seen, is that it still doesn't really work with the standard error cluster since you pass around arrays rather than the base cluster. Its not compatible anyway without adding a node to convert between them, it seems like making bigger changes is appropriate. Edit: thinking about Shaun's q below, the versions I've seen seem to be either (a) not the same data type or (b) the same 'type' but used in a fragile way. In both c
  4. That library is in the product (RT and DSC, same as the IO servers) as of 2014 and that is officially supported. Lol, true
  5. Don't forget about the existance of the much much newer ethernet rio targets -- if you can handle slower loop rates (and shoving all high speed logic onto the FPGA) they're really a lot easier to deal with (at least in my experience). Still, I think these benchmarks should give you a good idea: http://www.ni.com/product-documentation/10596/en/ and http://www.ni.com/white-paper/52642/en/ If you grab the excel sheet off the first one you can guess how much data is transferred and it estimates latency and delays through each node. For a basic enough example the second page show
  6. It may be challenging to make, but I think these web elements are nice: http://getbootstrap.com/components/#btn-groups You can label each item so you get the benefits of a radio group (in fact you could argue this looks more like a radio button than most radio buttons). Plus its actually a button, so you get the feeling that it takes immediate effect. Also, note the "Notify me of replies" when you post here on lava after the upgrade. Having the check or the x makes it pretty easy to understand the meaning, but thats because its also labeled well..."Notify me of replies" is an ob
  7. One other concern I have with priority/severity is...well how do you decide? If you're writing application-specific code, sure its reasonable. But developing a library? Something that may be critical to you may be minor or expected from the application, so anything reporting that would have to do conversion of some kind. How do you guys handle that sort of thing?
  8. Another more recent thread on the same topic you may not have seen: To me, when I see needs like "multiple concurrent errors and priority/severity" it sounds like the real interest is in better way to report errors, not handle them. I mean, I can count on 1 hand the number of times I actually check the specific error code programmatically (TCP errors come to mind, sometimes file I/O). More often I either handle any error coming from a function or sequence of functions, or just spit it up to a log or to the user. From that perspective, it recently occurred to me that syslog (the new
  9. I can't find any validation of this statement. From what I can tell, other solutions are similar to what JKSH suggested. For example: https://www.kepware.com/products/kepserverex/drivers/opc-ua-client/. I would also assume there is required to be a client-server interaction since OPC UA is capable of going over HTTP, which is inherently client-server. Are you sure server-server exists for OPC UA?
  10. if you mean connecting TO two opc ua servers I would guess yes.You specify what you want to connect to through the url. If you mean hosting two servers, I would guess yes but they would have to use separate ports. If this is what you were asking, why do you want two servers? I would assume in most cases people want their scada server to be the source of all truth, not the source of some of the truth.
  11. you can also use a service name with a port of 0. That way the actual port won't have to be fixed just the name. http://zone.ni.com/reference/en-XX/help/371361M-01/glang/open_application_reference/ ("port number or service name" section) http://zone.ni.com/reference/en-XX/help/371361M-01/lvdialog/vi_server_config_options/ ("port", "service name" sections)
  12. If I'm understanding your problem correctly, I think you can use the 'multiple output' function of string to IP to get all the IPs associated with that host name. If needed, you can do the same with 'localhost' and I think its returned on windows in the same order every time (letting you know if the VPN is connected if your vpn works that way). If your VPN always has the same subnet, you could also just OR the returned list with the VPN subnet and see if you get a match. If not, find the IP which matches your local IP address. Something along those lines.
  13. Not too long ago someone turned me on to the indeed trends page. I don't know how useful the data is but if anyone hasn't seen it its kind of neat: http://www.indeed.com/jobtrends/q-labview.html Which looks negative, but then you compare that to other languages and.. http://www.indeed.com/jobtrends/q-labview-q-python-q-java-q-C%23-q-C++.html?relative=1 In relative terms, python is a huge winner. If you add in standard labview terms you get these interesting compares: http://www.indeed.com/jobtrends/q-labview-test-measurement-q-python-test-measurement.html http://www.indeed.com/jobtren
  14. Ah but how much has scada changed since 1996? Everything is still basically just modbus with valve icons, right?
  15. I saw a conversation (argument) about that at some point but I don't recall the conclusion. I think there are arguments for a global install as well as a local install, depending on the tool. For example I'm assuming nobody is arguing this should be project-specific. On the other part (NPM) I thought it was an interesting idea and did some looking around. Chocolatey (despite its stupid name) seems to be relatively popular and the spec file is fundamentally the same as the vipm spec file with some added features (like wildcards): https://github.com/chocolatey/chocolateytemplates/blob/maste
  16. Lack of dynamic UI generation or easy ways to compose UIs (xcontrols being excluded from the easy category in general). If we're being really simple, for example, you could theoretically concatenate two sections of HTML and the website will render the 'child' and 'parent' data more or less as expected. .Net has something similar with xaml and windows forms also allow pretty simple creation of controls if I'm not mistaken. So for example one of the methods could be "add your controls to this container in this pane" and poof you get a single interface with both sets of info. No that makes
  17. Minor style point: I think its nicer if each class just returns an array, and you build up that array in each successive child. That way if someone says "oh I don't want this so I'm not going to wire it up" it won't hurt as much. I was thinking the same as shoneill: The ACBR should call a static dispatch method and then the static dispatch method just calls the DD method. This works great for normal ACBR code but its more of a challenge because you also want to insert the VI into the subpanel...so all you'd get is the static, not the called DD. I suppose you *could* do something like wha
  18. I don't think lv is really going to provide an easy solution here. Mercer wrote this (http://forums.ni.com/t5/LabVIEW/An-experiment-in-creating-compositable-user-interfaces-for/td-p/1262378) a while back but... As to your specific code, I don't know that all those methods would work in an exe and its pretty fragile. It would be nicer to just give the parent a dynamic method for "get user interface(s)" and another DD VI to be the connector pane for those UIs, and you'd call them with start async call (rather than setting the FP elements by name). You might also take a closer look at the CE
  19. I like that you decided to simplify the RTU serial read...I was stubborn and wanted to follow the spec, I think that was a mistake. Serial APIs have come too far since RTU was created. The visa lock thing is neat, I didn't know that existed until recently. My only comment there is that if you went with a DVR for both you could put that in the parent class so you can't execute a query unless the parent lets you, which feels nicer to me. Probably not any real reason to do it. I also like that you somewhat simplified the class hierarchy. I can tell you right now I've never seen anyone mak
  20. No, numerics, bools, strings, and arrays of the same. Doesn't sound like you're using it for an appropriate use case -- if every access is completely dynamic then yes there is no point to it vs a lookup. where it shines is neil's use where there are a fixed set of tags which you want to share globally but, being fixed, you can cache the lookups for. An equivalent but sometimes slower implementation would be using your variant repo where every contained value is a dvr or queue or notifier. The dvrs can be slower if, as in the opc ua situation, you want to access a large number of elements
  21. It wouldn't be hard to change the XNode to take a DVR of a variant rather than the variant itself. I did something similar so it would take an object and it was a lot easier than I thought it would be. For OPC UA in the past I've used the CVT and just made a small process which reads each OPC UA data value and copies it into the CVT. Then you can define groups for each of your tags and read data by group. NI made something very similar recently, although not as nice as this variant repo. The advantages though are that it has some metadata (last update timestamp, whether or not the valu
  22. For the state part of the question: It also depends on how likely it is for someone to change settings from a different console. I've worked primarily on applications where this is a risk (HMI1 and HMI2 can both read from and change settings on DeviceA). As such, I tend to favor always always always storing the model on the device. HMI1 says "here is the settings I think you should have" and then DeviceA takes those settings and configures any attached devices appropriately. Ideally, you'd have some sort of subscription mechanism set up so that HMI2 knows HMI1 made a change, but... This c
  23. Probably not, its designed to handle the situation that sometimes came up prior to the RT-cDAQ where you needed a RT processor but didn't care about the FPGA. The goal was to make a simple daqmx-like API for that specific use case. That having been said, its so simple that I've used it as a starting point for any streaming acquisition from the FPGA, for example you could be processing data, and then wanting to stream up the results. So in the acquisition loop instead of reading directly from I/O you could read from a target-scoped fifo or a local register. Its true value to me, now tha
  24. I'd recommend just using this: http://www.ni.com/example/31206/en/ It attempts to simplify the problem. If you want to understand it better, make sure you take a look at this: http://www.ni.com/pdf/products/us/criodevguidesec3.pdf starting pg 14 ("90" in the PDF)
  25. Theres a bunch of those, to the point that I don't find those properties in the help very trustworthy. I believe the explanation is that it can work on RT in interactive mode with the front panel open but not in an exe form? It will definitely work on the linux crios with displayports, as you have to check a little box which tells labview to compile it with the UI components. You can use an invoke node on the VI, I think (control value.get all) but then you lose the signalling property nodes.
  • Create New...

Important Information

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