Jump to content

Lessons learned from updating a cRIO


Tim_S

Recommended Posts

Still learning about the cRIO, but thought I'd share some of what I've learned recently. Some background on what was going on...

 

We had a driveline failure on two test stands out at customer site. There are sheer pins in the driveline designed to fail rather than send massive torque through a gear set in ways that is just BAD as it can lead to dynamic testing of the hard guarding (which is always fun!). Long story short, there was a failure more of the sheer pins that required detection of the sheer pins breaking. Worst case conditions is the break occurs at 6000 RPM and the only thing that we have already in the system is a 1 mm wide match mark on a 25 mm diameter disk. We found some laser sensors that could pick up the mark and bench tested the system. Everything looked good, so we integrated the bench test in the project, compiled everything and went to update the cRIO. This involved adding C series modules (electrician on site) and remote update of the cRIO application and bitfile through TeamViewer.

 

Lessons learned...

1. Install the NI-RIO driver on a PC connected to the cRIO before it is 1000s of km away. Transferring 4GB of installer over a flakey TeamViewer connection is not recommended.

 

2. Replication and Deployment (RAD) utility works well for the RT portion, but may not be able to install a bitfile to the FPGA.

 

3. The example "Get & Set Real-Time System Image" can work when RAD does not. Building the example into an executable that can deploy a selected file is very useful.

 

4. It is possible to create a image using RAD without errors from an identical cRIO that does not have all of the C series modules. There will not be an error, however the image will not deploy/set (sometimes without an error message).

 

5. Shared variables can function correctly with different LabVIEW versions (person helping me accidentally converted everything to 2015 for the image that did eventually install).

 

I'm sure I'm missing something, so would appreciate any insight people have.

Link to post

1. I would download from NI directly or host the installer and download from there on the remote PC.  Not a direct transfer.

2. We have had no issues using the RAD for RT and FPGA updates.  What did you discover?

3. 

4. 

5. This has proven useful when we migrated several dozen tools from LV 2010 to 2013.  Host PCs were used as backups at times during the migration, and sometimes they were of differing versions between tool and PC.  Of course, other things may break instead...

 

Props for successfully making a change of this magnitude remotely.  We update our tools remotely, but always after testing the procedure on a couple that are in the shop for maintenance.  Not really an option for this application.

Link to post

1. I would download from NI directly or host the installer and download from there on the remote PC.  Not a direct transfer.

2. We have had no issues using the RAD for RT and FPGA updates.  What did you discover?

3. 

4. 

5. This has proven useful when we migrated several dozen tools from LV 2010 to 2013.  Host PCs were used as backups at times during the migration, and sometimes they were of differing versions between tool and PC.  Of course, other things may break instead...

 

Props for successfully making a change of this magnitude remotely.  We update our tools remotely, but always after testing the procedure on a couple that are in the shop for maintenance.  Not really an option for this application.

Thanks. 

 

I would have downloaded from NI directly, but had to deal with the customer's network.

 

I don't have a reason why RAD didn't work. It would always fail when trying to flash the bitfile. I dug up the logs with the two error codes I was getting in RAD:

-2147220304 at nisyscfg.lvlib:Restart.vi -- NI System Configuration:  (Hex 0x800404B0) Timeout while waiting for reboot. System is offline.

-52003 at nirioFlashWriteBitstream.vi -- NI Platform Services:  An unexpected software error occurred.

The PC and cRIO have a direct connection. There are no physical network issues.

Link to post

This is really good info, thanks for sharing your experience.  For #2, are you dynamically loading your FPGA Bitfile from disk (I'm guessing you are not)?  I have a feeling that if you did this, the RAD image would work (your bitfile would just be another file transferred via the image and the RT app would load the FPGA on startup from a known location on disk - I haven't tried this but I'm guessing this is how it would work).

 

Dynamically loading the FPGA might not be the best option for all deployment scenarios of FPGAs but it would probably insulate you from this issue.

Link to post

For #2, are you dynamically loading your FPGA Bitfile from disk (I'm guessing you are not)?

 

That's a good point. I thought I was downloading the bitfile when the RT executable starts (using Download method), but was unable to locate the bitfile anywhere on the RT side.

Link to post

if you have the bitfile opened using the normal FPGA open, it should be compiled into the rtexe. It should also work if you are referencing it by path. The error you posted relates to flashing it on the FPGA, which is only necessary if you want the FPGA to boot before your exe does.

Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By Ricardo de Abreu
      Hi guys. This semester I'm starting a course system development for control and automation engineering, witch will be based on LabView. Therefore, my University doesn't have a NI hardware, even a MyRIO for us to test our VI and the teacher said that we should test our projects with our own Arduino...
      So, I have a little experience in Arduino and I know the basics for LabView. Now I'm in a point that I know that with Arduino I'll not take the best from LabView. I cannot even deploy a code to it.
      So, there is where my question comes in...
      I'm looking for a new board better then Arduino to use in the classes. I would buy a MyRIO card if I had the money but in Brazil this board is too expensive for me
       Witch one should I get that is closest to myRIO and less expensive than that? I would like to try de deployment of a VI and FPGA..... Is this possible?
      Thanks a lot for the help!
      Regards
    • By jdeantx
      With exciting projects in oil and gas, aerospace, utilities, and other industries, Vertical AIT is looking to hire skilled LabVIEW developers and architects in the Houston area. We are an Alliance Partner, and we specialize in embedded development.
      Requirements:
      - US citizenship (required by our contracts)
      - Industry experience in production software development
      - Embedded cRIO development experience (Real-time and FPGA)
      - Certification (CLD, CLA, and/or CLED) preferred
      - Must be meticulous and detail-oriented
      We offer great benefits, and we prioritize a healthy work/life balance.
      Learn more about Vertical AIT at www.VerticalAIT.com, and please send resumes to jobs@verticalait.com.
    • By grjgrj
      Hello. I need change some code for SbRIO-9626 with LabVIEW 2018. I have code from LabVIEW 2015. Right now I have only LabVIEW 2018. And I worked with it for SbRIO-9627.
      LabVIEW FPGA, LabVIEW Real-Time, NICRIO1800 driver istalled.
      And I install Xilinx ISE 11.5 Compilation Tool too. 
      When I start compilation FPGA VI I got error about problem with compilation too (see attachment picture).
      Could you tell me how I can solve this problem? 
      It is very important. 

    • By IpsoFacto
      I've got some weird stuff going on with a cRIO project I'm working on wanted to get some opinions on it. The basic architecture is a set of classes that do some process. That process registers with a server. The internal data of the process is held in a DVR and the server get's access to that DVR. Clients use TCP to ask the server to do something, the server makes a call against the classes DVR and returns a response to the client.
      To simplify the issues I'm seeing I created a class that internally just increments an integer every 500ms. The client asks the server what's the current count, the server asks the Counter class and returns the answer to the client. This works perfectly fine when running the VI in the IDE. When built it connects, will get the JSON message back, but always gets a default value from the DVR call (zero, in this case). As soon as I open a remote debug panel to the cRIO, everything is working. The count is correct, the client calls work, just like normal. As soon as I right-click, close debug, it goes back to zero. Open debug works, close debug, back to zero. I know the DVR isn't getting dropped because the count continues to increment while not in debug, the process is still running happily with no issues.
      Here's a few screenshots of the code;
      Count Class process (get the count, increment, write it back to the DVR) - Counter Class process
      You can see the DVR vi's are actually vim's using a cast. I can't imagine that's the issue.
      Server Side call - Server Side calls
      All this does is get the count from the DVR (same as above) and wraps it in JSON and passes it back to the client as a JSON string.
      I also implemented an Echo class that ignores the process and DVR's, it just takes whatever string you sent form the client to the server and passes it back with a prepended "@echo". This works when running as an executable with the debug turned off so I know the client, server, and the server/class calls are all working as expected.
      Any thoughts here would be welcome, thanks.
      edit: I added the any possible errors coming from the variant cast to the JSON reply. When the debug is open there are no errors, when the debugger is closed it throws error 91, but the in-place element structure reading the DVR does not throw any errors. How can a variant not exist until a debugger is opened and than it magically exists?
      edit: the internal data dictionary is a wrapper around a variant attribute, I wired out the "found?" terminal all the way out to the JSON reply and if the debugger is open the attribute is found, but not if the debugger is closed. Anyone have issues with Variant Attributes in Real-Time?
    • By prabhakaran
      Hi,
       
       
      I am trying to use image convolution inside FPGA. My Image size is around 6kx2k. The convolution is applied properly until 2600 pixels in x resolution. After that, the values seem to miss previous row data. 
       
      In Detail: As convolution is matrix operation, image data needs to be stored for the operation. But it seems there is an inadvertent error storing only 2600 pixels per row inside FPGA. And hence the filtered output is calculated assuming these pixels to be 0. 
       
      I have tried with different image sizes, different convolution kernels, and also in different targets (cRIO 9030 and IC 3173). All results are same.
       
      I have attached a screenshot of FPGA VI and an example image.
       
      The example image shows an input image of 4000x2500 of same pixel value 16.The kernel is 3x3 of values 1 with divider=1. The RT image is processed using IMAQ convolute inside RT controller and has value 144 [(9*16)/1] for all pixels. But the FPGA processed image (zoomed in) has 144 until 2597 pixels and then 112 (7*16- showing 1 column of 2 rows missing) at 2598, 80 (5*16- showing 2 columns of 2 rows missing) at 2599 and 48 after that (missing 3 columns of 2 rows- current row is always present). This shows the data is missing from the previous rows after 2600 index.
       
      Is there some mistake in the code or any workaround available?


×
×
  • Create New...

Important Information

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