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.
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.
05-17-2019 09:56 AM
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?
05-17-2019 11:00 AM
That sounds good to me!
05-21-2019 12:39 AM
I think that is a great idea, good initiative! 🙂
08-09-2019 06:55 AM
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?
08-13-2019 04:25 AM
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 🙂
08-20-2019 08:35 AM
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. "
08-20-2019 09:04 AM
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?
08-21-2019 03:19 AM
That would be great if you could do, Peter. 45 min is that ok incl. discussions?
08-21-2019 03:25 AM
Ok, I can do that. 45 min should be ok. 🙂