<html><body><div style="font-family: times new roman,new york,times,serif; font-size: 12pt; color: #000000"><div data-marker="__QUOTED_TEXT__"><div style="font-family: times new roman,new york,times,serif; font-size: 12pt; color: #000000"><div>Hi Nick and Nathan, <br></div><br><div>The cause of the 200ms time gaps may be from how the timing loop in LabVIEW is set up. I have few changes to the timing loop to try to see if we can maintain the 5Hz EPICS update rate and remove the 200ms time gaps.<br></div><br><div>One thing to note before changes are made: deploying to the Fast-DAQ cRIO does momentarily interrupt comms with the cRIO, tripping an interlock for a controlled dump. Because of this, any changes should not be made when the magnet is powered.<br></div><br><div>Best regards,<br></div><div>Tyler<br></div><br><br><hr id="zwchr"><div><b>From: </b>"Nicholas Sandoval" <sandoval@jlab.org><br><b>To: </b>"Ruben Fair" <rfair@jlab.org>, "Tyler Lemon" <tlemon@jlab.org><br><b>Cc: </b>"Wesley Moore" <wmoore@jlab.org>, "Nathan Baltzell" <baltzell@jlab.org>, "Probir Ghoshal" <ghoshal@jlab.org><br><b>Sent: </b>Monday, January 30, 2017 8:05:10 AM<br><b>Subject: </b>Re: HallB torus/solenoid fastdaq time gaps<br></div><br><div>Hi Ruben and Tyler,<br><br>Related to problem two that Nathan described below is individual time stamps for each VT. <br><br>The cRIO was picked for this application because of the capability to sample all voltage taps in parallel. We should not have different time stamps for each set of samples. Every 1/2000 set of 24 VT samples should have a single time stamp that allows tordaqgui to align them. This is not the case when reviewing the raw data in Excel for example.<br><br>The investigation should determine if in fact the cRIO is sampling each channel at different times or if this is just a time stamp that gets added after FPGA or some phenomena in the buffering.<br><br>This seems to be the reason why Probir and I were unable to find the exact combination of voltage taps that stacked up resulting in the 3000A fast dump tripping the PLC comparator even though both streams of data should be the same.<br><br><br>Best Regards,<br><br>Nick<br><br><br><br><br>----- Original Message -----<br>From: "Nathan Baltzell" <baltzell@jlab.org><br>To: "Ruben Fair" <rfair@jlab.org><br>Cc: "Tyler Lemon" <tlemon@jlab.org>, "Nicholas Sandoval" <sandoval@jlab.org><br>Sent: Saturday, January 28, 2017 9:08:00 AM<br>Subject: Re: HallB torus/solenoid fastdaq time gaps<br><br>Sure, sounds good.<br>-Nathan<br><br><br>On Jan 27, 2017, at 11:05 PM, Ruben Fair <rfair@jlab.org> wrote:<br><br>> Thanks Nathan<br>> <br>> Tyler will be investigating this phenomenon further. Perhaps he can come and talk to you sometime next week?<br>> <br>> Regards<br>> <br>> Ruben<br>> <br>>> On Jan 27, 2017, at 10:18 PM, Nathan Baltzell <baltzell@jlab.org> wrote:<br>>> <br>>> Hi Ruben,<br>>> <br>>> I heard you are wanting to solve the time gap problem in fastdaq data and thought I'd comment on some things we discovered during torus commissioning.<br>>> <br>>> There are at least two known possible sources of time gaps in the software side of this cRio-EPICS system:<br>>> <br>>> One is discrete (currently 200 ms) gaps. Those are because the EPICS records are updating at a fixed frequency (currently 5 Hz, using 2K-long arrays to result in 10 kHz data acquisition), and there are instances where updates get missed between the cRio and the softIOC which result in fixed (200 ms) time gaps. The first time we saw that error was after increasing the data acquisition rate from 2 to 10 kHz (i.e. increasing the EPICS update rate from 1 Hz to 5 Hz). Even at 10 kHz, we still didn't see much of this problem after software was working correctly, but a fixed time gap size is indicative of this problem.<br>>> <br>>> Two is random jitter. That comes entirely from the timestamp reported by the cRio, and the application tordaqGui currently honors the timestamps from the cRio. Before the increase from 1 Hz to 5 Hz that jitter was at most few-ms. After the increase, it became 10s of ms.<br>>> <br>>> Another important point is that the EPICS Live Fast-DAQ screen contains zero information about time gaps. It's good for injecting signals and looking at noise levels, but completely useless for understanding time gaps.<br>>> <br>>> Regards,<br>>> Nathan</div></div><br></div></div></body></html>