-
Posts
458 -
Joined
-
Last visited
-
Days Won
17
Content Type
Profiles
Forums
Downloads
Gallery
Everything posted by viSci
-
https://www.rti.com/products/benchmarks
- 72 replies
-
- networkcommunications
- datasocket
-
(and 1 more)
Tagged with:
-
Yes I have been using it quite a bit on a roadway monitoring project with 50 cRIO's. I use it to handle all of the cRIO system state and tag data publishing. We are still in the early stages of testing but it seems to be working very well. The LabVIEW version of RTI DDS is a subset of its full capability. RTI has been slowly adding features but it still does not support basic things like events. Judging from the forum posts, the toolkit is largely unknown in the LV community. I think if more people adopted it, it would garner more love and attention by RTI.
- 72 replies
-
- networkcommunications
- datasocket
-
(and 1 more)
Tagged with:
-
It is disheartening for those of us who develop for the cRIO to see NI come out with a cool product like systemlink but in a misguided marketing strategy have totally ignored those of us toughing it out in the trenches trying to develop secure and robust DDS capability for the cRIO. Even basic stuff like cRIO image management and software deployment, which systemlink handles nicely have been bundeled exclusively in the prohibitively expensive package that NI is trying to sell to electrical utilities.
- 72 replies
-
- networkcommunications
- datasocket
-
(and 1 more)
Tagged with:
-
It's not exactly native but the RTI DDS api has been included in the past few LabVIEW releases.
- 72 replies
-
- networkcommunications
- datasocket
-
(and 1 more)
Tagged with:
-
Messenger Library LV2019 compatibility
viSci replied to viSci's topic in Code Repository (Certified)
Just checking in to see if you have been able to do any LV2019 testing on this issue yet... -
Messenger Library LV2019 compatibility
viSci replied to viSci's topic in Code Repository (Certified)
Yes it appears to get hosed up inside the TCP Listener Actor. The funny thing is that I can compile an exe and run on my cRIO just fine, it is only via the IDE that there is a problem. This has been working with LV 2018 for many months without issue so it appears something has changed in LV2019. -
Since upgrading to LV 2019 I am seeing issues with an existing application running on a Linux based cRIO. The deployment process itself seems to be much slower and this initial section of code is causing the cRIO to disconnect from the development system. When the execution gets to the TCPEventMessenger Create subvi I get this popup and execution is aborted. Any thoughts?
-
Just in case someone else stumbles across this problem... It turns out the the cRIO-9056 has TSN capability built in so it will automatically try to slave the AI sample clock to a 1588 master if one is present on the network. In my case the master clock is not disciplined which wrecks havoc on the AI HW timing as it is only software based for the purpose of syncing the cRIO to the PC's clock for uniform relative accuracy. The solution to the is to use an obscure DAQmx property as follows... Add a DAQmx Channel Property Node to the task, select the General Properties >> Synchronization Unlock Behavior property and set it to Ignore Lost Sync Lock.
- 1 reply
-
- 2
-
At my wits end with this... When 1588 timesync is running it appear to interfere with DAQmx AI timed tasks. I am seeing strange errors -200284 (buffer underrun) or -209836 (The devices in your task cannot be synchronized) when I start my DAQmx task with 1588 engaged. When I disable the 1553 master on my network or remove the 1588 driver from the cRIO everything works correctly. To simplify testing I am using a DAQmx example - Thermocouple - Continuous Input.vi to do my testing. I do not have any HW sync modules just plain C series AI modules so there should be no attempt to perform any AI clock slaving since this is a software only 1588 system. BTW I am using the latest 19.0 drivers and LV Dev. I also see the same behavior in 18.5. Your thoughts please...
-
Curious to know more about the performance issues you were seeing with DAQmx on the cRIO. I would think it should be fairly high performance.
-
The Cutting Room Floor: Interesting finds in LabVIEW resource files
viSci replied to Sparkette's topic in LabVIEW General
along time ago I ran across an interesting paper by Monnie. https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=664322 I used some of his ideas as the basis for this... http://viscience.com/blog/portfolio-3/ -
BTW, which websocket library would you recommend for command-reply use cases on a Linux RT target?
-
What about the port service name locator, could that be a problem as well? I was planning on using RTI DDS for all network communications but the LabVIEW wrappers provided by RTI and now included in LV2018 have some shortcomings. Things like no native support for command-reply, no events and issues with strings within a cluster that start with a numeric digit pushed me to consider Messenger...
-
I am using cDAQ's with Linux RT but I suppose I could still use websockets, right? In the meantime I am trying out on-the-fly creation of Messenger remote connections to my cDAQs. It is not very fast ~50ms total transaction time per cDAQ but it might do since the command response side of things is more supervisory control of the overall system. For status and data collection I am using RTI-DDS which is blazing fast. One concern I am having with Messenger is that on occasion I have seen the 50ms transaction times suddenly increase to 5000ms. Shooting in the dark, I am wondering if it could have something to do with NI Service Locator sync between client and servers? Anyway, it would be nice if the messenger library had the option of specifying static port numbers instead of service names.
-
I also need something that can handle situations where the cDAQ is not present or drops out and needs to be reconnected with. I think I maybe trying to use the wrong tool for this application. I might be better off with a topic based DDS that has inherent reconnect capability.
-
Hello all - I am trying to figure out a way to use the TCP Messenger to create a PC client that can send messages to up to 52 remote cDAQs. I used your simple TCP Client Server example to start off with and it works fine for a single cDAQ server. The problem is that I do not want to have to launch 52 actors in my client code pointing to each of the 52 cDAQ IP addresses. Is there a way to just send simple messages to the server without have to launch an actor or perhaps reuse an actor by programmatically pointing to the IP address I need to talk to at any given time?
-
I use the dll wizard often and it has saved me a lot of time. It took awhile to understand how to massage the .h files into something digestible but once I got the hang of it, it was worth the effort. The error handling is pretty good at pointing you to the offending spot in the .h file. I think that the wizard has improved over time so if your last exposure was years ago I would give it another try.
-
Thanks - I was able to use your suggestion to get the current cursor position and it worked correctly. I was able to construct and insert a proper table in an open word document.
-
I would like to obtain a .net reference to an open word document and add a table at the current cursor location in the document. I can already do this using a crude automated copy and paste method but would like to be able to add a proper word table into the document. Using the .net interfaces I think this is possible but so far have not been able to get it to work. Has anyone tried to do this before?
-
Hey Neil - I am in the process of designing a 50 node (RT Linux) system with around 100 tags per node. I was briefly thinking about using NSV's or RTI-DDS but now am thinking that OPC-UA would be a better solution for publishing tag values. Do you have any performance metrics like tag updates /s for your implementation?. I have seen some pretty nice OPC UA Client Viewers that function like the NI DSM but would prefer a native LV viewer. Would you consider offering your OPC UA Viewer and Data logger as a toolkit?
-
Transfer Image from cDAQ-9133 Linux RT to cDAQ-9133 WES7
viSci replied to viSci's topic in LabVIEW General
With the help of my NI inside sales rep, I was able to get a cDAQ Linux installation image and instructions to restore and existing Linux chassis or convert a WES7 to Linux. NI was very protective with this stuff even though the Linus RT source is published on GIthub. -
Transfer Image from cDAQ-9133 Linux RT to cDAQ-9133 WES7
viSci replied to viSci's topic in LabVIEW General
I was told if you are within the first 30 days you can send it back to NI and they will replace it with your OS of choice. In my case that is not possible so I have to find a way to do it myself. I found this document http://www.ni.com/product-documentation/54592/en/ which alludes to being able to restore a cDAQ image or even make it a dual boot device but details are lacking. -
I have two cDAQ-9133 controllers, one with WES7 and one with LinuxRT. I would like to convert the cDAQ 9133 with WES7 to LinuxRT. Both cDAQ's were purchased 6 months ago to determine the best OS for our application. I have gone through all of the forums and it seems like I might be able to use the NI recovery disk or possibly a disk cloning utility like acronis or similar. Has anyone had success doing this?
-
Sharp LV developer needed for design / implementation of large scale distributed data acquisition system. Skills Needed: LabVIEW Real-Time, Publish Subscribe, Messaging Protocols, Data Distribution Services (like RTI-DDS, RabbitMQ, etc), DB Stored Procedures, Tree Structures, TDMS. This is a 9-12 month contract position in Gainesville, FL. Please send CV to mike.sachs@viscience.com
-
Just curious, what is the advantage of the MQTT implementation over off the shelf RTI-DDS now built into LabVIEW for windows and RT Linux