• Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About cragjumper

  • Rank
  1. cragjumper

    Streaming Vs C&r Timing With Two U6's

    Thank you so much for the thorough and quick reply - I suspected there had to be something with latency in getting the data and assigning a timestamp. That clears up a lot. I am a little confused as to your last comment, however, about looking at all the data in DAQFactory. Is the data presented in each channel history table different than what gets exported? With streaming channels, would the table history timestamps be identical for all channels, or would they differ slightly by the latency of scanning between channels, which then is eliminated when the data is logged/exported and placed all under one set of timestampts with zero align? Also, looking at the data in DAQFactory doesn't change the main issue that streaming and C/R timestamps aren't aligned, correct? Thanks again!!
  2. The Overall Question: Is there a difference in how DAQFactory or the Labjack hardware assigns timestamps during streaming vs. command/response mode? For example, if I were to record a single square wave input (20 Hz) on two different labjacks, one streaming data and the other using C&R with both labjacks collecting data at the same frequency (250 hz), would I not only see the same frequency square wave but have the square waves line up fairly close to each other (within 1/250 s) if I were to plot them using the data and respective timestamps provided by each labjack? The Context: I'm currently streaming data from one Labjack U6 (let's call it LJ1_stream) and using command/response to collect data on another U6 (LJ2_CR). The reason for this is that a) I need 6 timers, hence 2 different labjacks and one of the timers is to record a rotary quadrature encoder that rotates too quickly for streaming (due to the 1 edge/33 usec processing limitation). Therefore, 4 rotary encoders using duty cycle timing (mode 4) are read by LJ1_stream and 2 quadrature rotary encoders using quadrature timing (mode 8) are read by LJ2_CR. I've set the streaming to 250 hz and the C&R timing to 0.004 seconds (which I realize is faster than recommended for C&R and could be part of the issue as discussed further below) to also provide 250 hz measuring. A common 20 hz square wave generated by a function generator is also being recorded on both labjacks, as well as an experiment start signal and a valve command signal, which both start low and go high when respective buttons are pushed. Data is collected and exported (not logged) using expressions of the form Channelx_Data[Experiment_startTime,Experiment_endTime] where Experiment_startTime = systime() at the beginning of the experiment based on a button press and similarly for Experiment_endTime. The data from LJ1_stream and LJ2_CR are exported as two separate export sets, with All data points (aligned) and zero align threshold. Channel histories are 3000 for LJ1_stream and 4000 for LJ2_CR, since my experiments only run for ~2-3 seconds at a time. LJ1_stream, in addition to the 8 channels being occupied by the four timers and the three common digital input signal channels, also has 5 analog signal channels and one other digital input, for a total of 17 streamed channels. According to the 50000 max sample rate, 17 channels should correspond to a max scan rate of 2941, or a minimum of 0.00034 seconds between scans, so running at 250 hz should be slow enough. LJ2_CR has the 4 channels for the 2 quadrature timers, and the three common digital inputs. The Detailed Problem: There are experiments where the common signals are being recorded at very different timestamps from LJ1_stream compared to LJ2_CR. For example, in one experiment, the experiment start signal went high at -0.193 seconds on LJ2_CR vs. at 0 for LJ1_stream (obviously using the LJ1_stream experiment start signal time as the basis for subtracting the DAQFactory time into useable time for both LJ1_stream and LJ2_CR). There are other experiments where the effect is less pronounced, but still off by >2 timesteps (e.g. experiment start signal goes high at +0.009s on LJ2_CR but is recorded at 0 for LJ1_stream). Some Thoughts: 1) Running LJ2_CR at 250 hz is too fast? According to the labjack specifications (sec 3.1 and 3.2 of labjack U6 manual), one complete scan of 6 channels (2xquadrature timers and 2 digital inputs) in C&R mode would take about 8.5 ms, which corresponds to roughly a max record rate of 117 hz. However, in examining the quadrature encoder data recorded at 250 hz using C&R on LJ2_CR, there doesn't appear to be any major issues other than some occasional data dropouts that occur. The data still looks fairly smooth and uninterrupted. Is it possible that the timer channels are recorded more accurately because they're interrupt driven rather than the digital signals (are they polled?)? 2) Is this an issue with using export rather than logging? Any other suggestions or thoughts would be greatly appreciated as to why timestamps aren't lining up, and I'm happy to clarify anything as I realize this is a very specific and detailed question that may not be as applicable to the general public.
  3. cragjumper

    Streaming Issues - Crosstalk?

    Hi all, My sincere apologies for not responding sooner - for some reason I'm not getting an email saying that my forum questions are being responded to. I've just been living with the issue since my experiments are short and I can just stop and restart data collection to clear the problem. I did see the previous forum posting on crosstalk that seemed similar to my issue prior to submitting my posting, but I did have all the latest firmware updates and UD, and I'm running DAQFactory release 5.87a build:1972. I actually tried using the beta firmware prior to posting, but not only did it not fix the problem, but I had some communication issues with the U6 after that and had to revert back to the previous firmware (non-beta version). I will try to install the beta firmware and latest driver when I have a chance to see if it will fix the issue. Much thanks for the support!
  4. Hi all, I'm running into an issue when streaming 9 channels (4 pairs of duty cycle timer channels to record 4 rotary encoder signals, and 1 channel to capture EIOFIO) on my U6. At low scanrates (scanrate = 1000), everything works fine. However, at higher scanrates, say, >3000, I've seen behavior that I can't quite figure out. At the higher scanrates, if I leave DAQFactory collecting data, everything works well in the beginning. However, after a random amount of time (I think it's random since I haven't found a pattern or correlation to any other factors yet) the data abruptly starts to go haywire. It looks as though data is being put into the wrong channels - e.g. Channel224 data starts showing up in Channel201, etc. No data is showing up in the proper channels. You can see the channels shifting as well, as after another random amount of time, the data being displayed with shift, again with channels being expressed in different ones. All the data shifts simultaneously, as in, all the channels will suddenly swap with one another in an undiscernable pattern. However, once I stop the streaming and restart data collection, everything is fine again, until after an unspecified amount of time, the data will again go haywire. I'm tracking the backlog, and it isn't near the 100000 sample backlog (at most around 6000 samples). I've checked the physical hardware signals being input, and they aren't changing, so I know it's not the signals being input to the Labjack. I've tried swapping with different U6's and gotten the same behavior, so unless this is a hardware issue with U6's in general, it's at least not localized to a single piece of hardware. I've also checked to make sure that my scanrate is under the acceptable limits. With 9 channels, at 50,000 samples/sec max, yields 5556 scans/sec, so <5000 scans/sec should be fine. Also, the encoders output PWM at 244 hz, which translates to roughly 2 edges every 0.004098 s, which means with 4 encoders I'm getting at most about 1952 edges/sec, which is well below the 7000 edges/second limit specified for streaming timers in Appendix A. Has anyone seen similar behavior? Is this a DAQFactory streaming issue, or a hardware/driver interface issue with Labjack? Any thoughts would be greatly appreciated!
  5. Hi, yup, that's what the script says, but I was responding to the comment "BTW: that's a pretty weird calc for lsw/msw, but if it works..." from the August 14th post - I thought you were referring to my duty cycle calc.
  6. Hi all, I've been working on streaming some data, namely some digital inputs on FIO4-7. I'm successfully streaming channel 193 and getting good data. However, when I try to use scanrates>1000, I start running into timestamp issues, where blocks of data all have the same timestamp. My guess is that it's an issue using excel time - perhaps excel time doesn't have capacity for resolution > .0001 seconds? When I turn off excel time, it seems to run fine (obviously I have to calculate time differently since it's now seconds from 1970). In case I wanted to use excel time, do you know a way around the limitation in resolution? Thanks!
  7. Thanks for the response! I actually just saw it today - for some reason, I missed the notification that I got a reply, and happened upon my own post today while looking up another issue. Just wanted to share what I figured out to resolve the issues that I posted those few months ago: 2) With regards to doing calculations on streamed sets of data, what worked for me was simply creating a V channel and inserting the expression (Streaming_LSW/ (Streaming_LSW+Streaming_MSW)) * 100, where Streaming_LSW and Streaming_MSW are the channels receiving the streamed LSW and MSW for the timer in duty cycle mode. This automatically calculated the duty cycle using the data in the two streamed channels. Albeit, this limits you to only the data in the history, for me that was enough since my test was short. I then simply exported the Vchannel. As for the calc for duty cycle, I thought LSW = Signal High time, MSW = Signal Low time, hence duty cycle = high time / total time, where total time = LSW+MSW?
  8. How does this change if your data is being streamed in the two channels? I'm streaming data from a duty cycle measurement using Timer0. Rather than logging the MSW and LSW on two channels and then processing the data later, I'd like to calculate the duty cycle as the data is being captured and then only log the calculated duty cycle value. Any suggestions?
  9. Hi all, I've got my U3 measuring duty cycle using Timer0 and Timer1. Since I'm streaming the data, I've set up the configuration using sequences and setup four channels to read Channel 200, 224, 201, 225. I'm confident that I have the streaming working properly and am able to log the raw data (which consists of 4 elements - the LSW,MSW of Timer 0 and LSW,MSW of TImer1) without any issues. However, I'd rather not have to calculate the duty cycle for tens of thousands of points from the raw data for every one of my log files in excel. As such, I've been able to calculate the duty cycle within DAQFactory using both virtual channels and test channels. In my virtual channel, I've simply written the expression to calculate the duty cycle using the results of my data channels. My test channels receive the results of those same expressions from the Event tab of channels 224 and 225 using the AddValue command. So, I feel I can successfully calculate duty cycle values using two different methods. However, the issue is in trying to correctly log them. 1) From what I've read, I believe logging will not work with virtual channels, and as such must be recorded using export. However, I think export only exports the history of the channel, so if you happen to exceed the history, you'd be losing data. Is there another way to use Virtual Channels to actually log, rather than export, data? 2) When using the event tab of channel 224, I use the following expression to calculate duty cycle from the raw data for the LSW and MSW: DutyCycle_Calc.AddValue(DutyCycle_LSW/(DutyCycle_LSW+DutyCycle_MSW)*100) where DutyCycle_Calc is my test channel. When I use this form, nothing is logged from DutyCycle_Calc. However, if I use this expression instead: DutyCycle_Calc.AddValue(DutyCycle_LSW[0]/(DutyCycle_LSW[0]+DutyCycle_MSW[0])*100) I log a duty cycle value every few milliseconds but have a large number of raw data logged in between. I believe this is because the event is only being triggered when the packet from the streaming is written, and since the [0] only looks at one element of the package, only one piece of data from the packet is used to calculate a duty cycle. Is there a way to record a calculated DutyCycle for every piece of raw data that was streamed within a packet and have it logged? 3) On an unrelated note, does the channel # of a test channel matter? Or can these be arbitrarily set? Honestly, I'm still not clear on how to use test channels properly and couldn't find any direct explanations in the DAQFactory Manual. Any pointers to references would be greatly appreciated. If there's an easy and obvious answer to any of these questions (calculate in sequences and then somehow log the values?), I apologize, but I'd really appreciate some help either way, as I've really put a lot of time into figuring this out and haven't found a solution yet. Cheers!