Next Lund Meeting September 2019

[Karin_Hellqvist]

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?

[Peter.Norlen]

That sounds good to me!

[lindavallenhag]

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

[Karin_Hellqvist]

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?

[Peter.Norlen]

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 🙂

[Karin_Hellqvist]

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. "

[Peter.Norlen]

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?

[Karin_Hellqvist]

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

[Peter.Norlen]

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