LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Seeking Suggestions for my application

Solved!
Go to solution

Hello All,

 

I currently have an application where PC (host) gets data from sbRIO (FPGA to RT to PC) over TCP/IP. Since I have utilized all the FPGA pins, I need to expand my application and for that, I was hoping to add another sbRIO-9638. I wish to connect this new sbRIO to existing one. That way, I can leave the PC part of the code almost untouched and bundle all the data from two sbRIOs in one and then send it to PC. In a distant future, I wish to replace the new sbRIO with an ESP32 or something else to exchange some low level data.

 

Xonmyth_0-1716301143752.png

 

It is a must that I use another sbRIO and only the USB port. LAN ports are occupied. I do not know for sure if this approach will work or not. I already have one additional FPGA board (Third party) and sbRIO going to PC, utilizing HOST port on sbRIO-9638 will help reduce some wires.

Since I have limited time to finish this task, I am hoping if someone have any suggestions or knows that this will work or if they have done something similar in past. I am guessing that I can use the TCP/IP to exchange data between the new and old sbRIO. EDIT: If this cannot work, I will directly connect new sbRIO to PC.

I can provide additional details if needed.

 

Thank you for reading

X

0 Kudos
Message 1 of 10
(502 Views)

Can you use a LAN switch to connect all of the RIO's together?

0 Kudos
Message 2 of 10
(488 Views)

I would want to avoid doing that at all cost unless it is the only option. Since this will make all of our customers to buy network switches and most of them have some sort of network security that I typically have to bypass to get our devices to be detected on their network.

0 Kudos
Message 3 of 10
(484 Views)

I'm certainly no networking expert, but I think an unmanaged switch wouldn't cost much and wouldn't show up on a network anyway.

 

Wish I could offer some more advice but I haven't used the USB ports on RIO's much. You could probably add some USB to Serial devices and talk that way. I believe VISA is available for LVRT, and if you do your protocol correctly you could switch pretty seamlessly to an ESP-xxx chip later on without needing to modify your "main" RIO's code.

Message 4 of 10
(454 Views)

Thank you for your suggestion Bert. If need be, I will go down this route. Programming-wise I am more familiar with LAN too but application and usage-wise, I just finished dealing with a nightmare support. For some reason, some enterprise level network security does not like talking to RIO devices over LAN. They block it.

I think so too, VISA is there for LVRT. That is what my hope is to seamlessly switch to ESP. I am not that confident yet though hehe. I will keep educating myself in the meanwhile. I will add what I ended up doing here.

 

Once again, appreciate the input. 🙂

0 Kudos
Message 5 of 10
(448 Views)
Solution
Accepted by topic author Xonmyth

If you haven't done serial before, take a look at this video:

 

https://www.youtube.com/watch?v=J8zw0sS6i1c

 

Do a little poking around and reading up on the right ways to do it. The examples that come with LabVIEW are quite misleading- for example, if you find yourself looking to use the "Bytes at Port" function, you are doing something wrong and should reconsider your communication protocol.

 

Serial comms add a layer of complexity on top of TCP, in that TCP has an inherent "this is the whole message, here you go" function in it. With serial, you have to manually program in the "I'm done transmitting, here's the whole message" functionality yourself.

 

Since you're programming both ends of the serial link, this should be very doable. The short version is "use termination characters" but there's more to it than that. The video I linked above is a great one (assuming it's the one I remembered, lol!)

Message 6 of 10
(446 Views)

@BertMcMahan wrote:

Since you're programming both ends of the serial link, this should be very doable. The short version is "use termination characters" but there's more to it than that. The video I linked above is a great one (assuming it's the one I remembered, lol!)


Assuming ASCII based messaging, yes, use a termination character.  A Line Feed (0x0A) is the most common.

 

And, yes, I still get positive reviews from that video out in the wild.  I might have to review it, see what updates I could make, and re-present at a conference (need a reason to go to a GDev Con or NI Connect).


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 7 of 10
(435 Views)

Yes, I am reading and looking thing up. I guess issue is the bias in my head to do it the easiest way hehe. That is what masking some of the searches.

Yes, crossrulz's video saved my life once about 2 years ago and it may save it again. I would not be able to DO IT if it weren't for this video. 

 

I might be missing or misunderstanding something here, but based on what I know, one can access RT using TCP/IP or Network Shared Variables (maybe couple more options but these two are what I commonly have used in past) between PC and RT. Can you do serial communication between PC and RT? I know you can access serial devices via PC and RT (never tried on RT) but RT shows up as a network device. 

 

EDIT: I guess you can this way. https://forums.ni.com/t5/LabVIEW/Desktop-PC-RT-Target-communication-with-host-through-RS232/td-p/266...

0 Kudos
Message 8 of 10
(406 Views)
Solution
Accepted by topic author Xonmyth

@Xonmyth wrote:

I might be missing or misunderstanding something here, but based on what I know, one can access RT using TCP/IP or Network Shared Variables (maybe couple more options but these two are what I commonly have used in past) between PC and RT. Can you do serial communication between PC and RT? I know you can access serial devices via PC and RT (never tried on RT) but RT shows up as a network device.


I generally advise using TCP/IP or Network Streams.  I am on the side of using TCP/IP, I know plenty of people who prefer Network Streams.  It is not a fight I care about.  Use whichever one of those two you are comfortable with.

 

I have had all kinds of weird issues with Network Published Shared Variables.  They are slow (require updates and reading from a database, plus there is a buffer that needs to be filled or a timeout before the writing happens) and insecure (anybody on the network can change the value).  I have wasted too much time working around issues that derive from those two issues.  As the person who did a whole presentation on why global variables are useful, I will be the first to state that NPSVs are evil and should be abolished.

 

Yes, serial is possible on a cRIO.  I have not personally done it.  But you will need a serial port on both the PC and the cRIO.  I think the C-series serial modules require FPGA when using a cRIO.  I would have to do some digging to double check that.  Or you can try a USB-RS232 adapter on the cRIO, but if you are going that route, I would just use the TCP/IP over the USB port.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 9 of 10
(380 Views)

Thank you crossrulz, Yes, for now I am opting for TCP/IP as I can salvage most of my known-good working code. It will help with the timeline. Later if I use non-NI stuff, I may use serial. It may be cumbersome.

 

Although the code is known code and I adjusted it to talk between an sbRIO and a myRIO, I am getting an error 66 after the connection opens successfully. So figuring that part out. I might create another post if I cannot get past that.

 

I partially agree about the Network Streams -Easier than TCP/IP but can also give headaches. I have them in place for my main application along with TCP/IP (long story). It works fine for the most part but yes definitely some challenges with first attempt to establish a communication. Typically, I run into user or IT settings that I would have to get past of once it is out of the way, it works all the time. But again in my case on the coding side, it would have to be programmed carefully as it  retains last values, both good and bad.

 

When I get more comfortable with TCP/IP, I would prefer using it. Just a personal preference, not inviting a fight with any of my statements hehe.

0 Kudos
Message 10 of 10
(366 Views)