From Saturday, Nov 23rd 7:00 PM CST - Sunday, Nov 24th 7:45 AM CST, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

West Sweden LabVIEW User Group

cancel
Showing results for 
Search instead for 
Did you mean: 

Next Lund Meeting September 2019

Thank you for a great first event at our User Group, Linda and Johan.

If you want we can be at DVel's office, also at Ideon, for our next event. 
We talked about the beginning on the fall. Could September 18th be a good date?

0 Kudos
Message 1 of 9
(5,522 Views)

That sounds good to me!

0 Kudos
Message 2 of 9
(5,517 Views)

I think that is a great idea, good initiative! 🙂

0 Kudos
Message 3 of 9
(5,508 Views)

What do we want on the agenda?

Last time we talked about best practice, code review, templates in LabVIEW.
Anyone want's to volunteer with showing code for review/discussion?  

My colleague Martin Peeker afterwards volenteeres to talk about highlights from GDevCon that he will visit in two weeks. Would that be interesting?

0 Kudos
Message 4 of 9
(5,395 Views)

Hi,

 

I would be very interested in discussing error handling when using applications with FPGA and Realtime applications.

I have an application that is using an sbRIO with Ethernet communication. I have code on the FPGA, on the sbRIO and on the computer. It is not obvious how to handle errors in a good way and if anyone have ideas or experience on how to handle this scenario that would be very interesting. At least to me 🙂

0 Kudos
Message 5 of 9
(5,380 Views)

Talked to my colleagues about your question, Peter. They are happy to talk to you on the event, even though they don't really want to present something. We will have time for mingle and time to discuss these things.

One thing they shared and that I have also done is skipping the RT part of the application, only using the FPGA and the PC application. See further explanation from my colleague Per in Swedish:

"Vet inte om det finns nån best practice. Vi brukar ju i regel undvika kod på RT just för att slippa klyddet med klient/server setup och kod ska klara sig själv i alla scenarion. Man ansluter direkt till FPGA:n från PC istället.
Annars behöver man hantera nätverksproblem med watchdogs, checksummor, timeouts, reconnect och fulla buffrar etc. Meddelanden mellan klient/server behöver ack/nak och fel måste rapporteras till klienten och skrivas till log. Systemet kanske behöver startas om för vissa fel för att inte fastna i hängt läge.
Det blir en ganska stor källa till fel pga detta designval.Koden på FPGA:n är i regel väldigt hårdvarunära så där brukar vi inte ha nån direkt felhantering förutom typ felkoder eller status IO från sensorer.
I slutändan handlar det då mest om att ha en tillförlitlig Ethernet uppkoppling. Skulle det bli avbrott så får man felet på PC sidan där man kan använda felhantering som vanligt direkt mot användaren.
Så min rekommendation är att undvika fancy kod på RT och FPGA. Oftast klara man sig utan.Sen kan man förstås ha system som behöver köras helt remote och fristående av olika anledningar. "

0 Kudos
Message 6 of 9
(5,349 Views)

Thanks for the input!

I have not thought about skipping the entire RT bit for this project... I will consider it in the upcoming code rework. However we have a lot of stuff going on in this external equipment and only part of it is using the FPGA to execute. So my initial feeling is that we still need RT code...

 

If people are interested I can show the equipment and the code I have, with a following discussion regarding RT/FPGA in general maybe?

0 Kudos
Message 7 of 9
(5,343 Views)

That would be great if you could do, Peter. 45 min is that ok incl. discussions?

0 Kudos
Message 8 of 9
(5,334 Views)

Ok, I can do that. 45 min should be ok. 🙂

Message 9 of 9
(5,328 Views)