Calculation channel

[Jimmy1125]

Hello! I’m having a problem with a while loop. It gets stuck and won’t continue onto the next part of my sequence. 
while(Rawcounts [0] <175)

    Read(Rawcounts[0])

       If(Rawcounts[0] >131)

       ePut…I slow my LJTicDAC output)

        Endif

            Delay(0.2)

endwhile

I’ve tried it with and without delay. 
Am I missing something here?

Thanks Jim

[AzeoTech]

Is RawCounts ever going above 175?

Did you, by chance, create a global variable named RawCounts in addition to the channel named RawCounts?

Are you sure it isn't getting stuck in the ePut?

I would add a ? statement in the loop, right after the while():

? rawCounts[0]

Then look in the command / alert to see what the loop is seeing for rawcounts

[Jimmy1125]

Yes. Rawcounts goes above 175. Usually around 352 or so. No global variables. I’ll add the ? And see. Almost seems that it doesn’t read the channel fast enough. Maybe because of streaming? If I make a sequence with an ePut to start vfd, then do a while statement, it works okay. 
Definitely a learning process. 

[Jimmy1125]

Is it a problem with streaming and trying to read a channel at the same time? It seems like it’s reading the stream first and then the channel because by that time it’s already beyond the counts I want. 
I’ve looked at the channel table and it shows the counts increasing, but it just seems like the sequence is not picking up the counts until later. 
I tried streaming the counts channel at the same time and that doesn’t help. 
Can you give me an example? I tried different things. 
while(1)

    If(counts channel[0]<175)

also tried while(counts channel[0]<175). Etc but can’t get it to work right. 
Thanks

[Jimmy1125]

Also, would this work better in the channel event for the counter? Currently I’m trying it in a sequence, which I’d rather have. 

[AzeoTech]

I can't really address what the LabJack does when you try and trigger a single read of an input that you are also streaming.  In general I don't see why you would do that.  It'd be better to simply process the streaming data.  Now, streaming data has issues, namely that DAQFactory only gets the data in blocks.  This is why streaming can go so fast.  The trick is that since the data comes in in blocks that channel[0] is only being updated every blocksize number of points, so always looking at just [0] means you aren't actually looking at all the data.  For this reason it is often best to use aggregate functions to check the entire block.  Something like:

private lastStart = systime()-1
private end
while(1)
   end = systime()
   private datablock = rawCounts[lastStart,end]
   lastStart = end + 0.00001
   if (numrows(datablock) > 0)
      if (max(datablock) > 131)
         ePut(....)
      endif
      if (max(datablock) >= 175)
         break
      endif
   endif
   delay(0.2)
endwhile

I do some important stuff here.  One, I subset by time instead of index since I can't predict the block size, nor when this code will execute relative to the block coming in, since that is controlled by the LabJack.  By using time, I can simply request all points since the last loop (or 1 second worth at the start). 

Second, I capture my end time before using it.  So instead of doing datablock = rawCounts[lastStart,systime()], then doing lastStart = systime(), I capture the time in "end" and use that instead.  This ensures I don't miss data that comes in the time between the datablock line and updating laststart.

Finally, I use max() to find if any point in the last datablock is > 131 and >= 175.  If you were doing < or <= you would of course want to use min().

To test this I would recommend avoiding the ePut and just putting a ? statement in:

if (max(datablock) > 131)
   ? "ePut here"
endif

Then you would know the logic works, and then can deal with any hardware issues with trying to do an ePut() while streaming.

[Jimmy1125]

Seems like a lot of work just to count some teeth on a wheel and control a d to a output. 

[AzeoTech]

Yeah, computers are interesting that way.  Things that you would think are really hard to do, often can be done very easily on a computer, but at the same time, things that you would think are super easy, are actually kind of challenging.  Speech recognition is a prime example.  It is super easy to do as a human, but not so easy for a computer to do.  In your case, the issue is the streaming.  If you slowed everything down it would be a whole lot simpler and you could use your initial logic.  But if you are streaming high speed you have to deal with the issues that come with it, namely that data arrives in blocks, not single values.  This is an issue for any software running on a PC using streaming mode of hardware.

That said, you might look at using the LabJack's built in Lua scripting to handle the control.  The problem with DAQFactory (and any software running on the PC) is that it takes like 3-4 ms to communicate with the LabJack, thus the need for blocks.  But the Lua script runs on the LabJack itself, so doesn't have this bottleneck.  But then again, you'd have to figure out how to get Lua to work... 

[Jimmy1125]

I'm trying to read a counter that is counting teeth on a trigger wheel. I want the wheel to turn 2.25 times( count of 131) and then slow down so it will stop at counter of 175. I'm streaming three other channels and post processing that data but the counter is what controls how many times the wheel; turns. I can use my stroke channel to return the wheel to where I want but it isn't always consistent. With that said, can you look at my sequence cvpplot. It's acting weird. If I use a delay of 1.2, the wheel will stop on second turn at the spot called in my bdc sequence. If I increase it to 1.3, it turns 4 times and overshoots and stops on the other side of bdc. I would think that I could creep up on the delay until I get it where I want. 

SHOCKDYNO.ctl

[AzeoTech]

OK, a couple things to understand:

1) if you use beginseq() to run a sequence, it starts that sequence in a separate thread.  The other sequence will start, then the calling sequence will immediately move to the next statement.  

2) There is nothing predictable about how a sequence starts when using beginseq(), nor how Windows will task the calling sequence vs the new sequence (unless the priorities are different, but even then it is more of a suggestion in Windows.  This means that when you do beginseq(x) from sequence y, that x may get a chance to run 1 line, 10 lines or no lines before the sequence y gets to the line after beginseq().  It most cases it is 0.

3) DAQFactory uses threadpooling, but even then, starting a sequence in a separate thread is an expensive operation, meaning it takes more time than calling a sequence as a function.  Of course, if you need the separate thread, then by all means, but in general I think folks overuse beginseq(), probably because they don't realize they can call the sequence as a function.

My guess is you just need to replace all you beginseq() in cvpplot with function calls:

ePut(...)
delay(1)
startStream()
ePut()
delay(1.2)
ePut()
bdc()
delay(0.1)
stopStream()

Note that those last two lines won't execute until bdc() is done and bdc() has a loop, so the stream won't stop until the loop in bcd completes.

Moving on to your initial problem of counting teeth, I would say that to stop at 175 exactly, even with a slowdown at 131, you probably have a max RPM of about 3000 rpm (one rev (52 teeth) per about 20ms).  It will be easier to implement if you stay well below that.  If you need faster you are going to have to do this closed loop logic in a micro, PLC, or inside the LabJack itself.  This is because, a) DAQFactory runs on Windows and Windows is not preemptive multitasking, meaning it can decide not to give DAQFactory any processor power for 10-20ms without warning, and b) PC->LabJack comms I believe are around 3-4ms for each query.  I don't know how streaming impacts that, but I wouldn't think you could do reliable closed loop control with a loop time of less than 10ms in the best circumstances (i.e. just reading a single input and controlling a single output).  20ms is more reasonable, thus the 3000rpm number.  But as I said, I don't know how streaming is going throw that.  I am guessing it is interrupt driven in the LabJack, so while it is dumping data over the USB, DAQFactory isn't going to be able to read anything else from the LabJack or control anything.  

You might consider a second LabJack to help, especially if it is not used for streaming, it is Ethernet, and you use Modbus instead of the LabJackM/UD device (i.e. a T4 or T7).  Then you'll bypass the LabJack driver, which is busy handling your first LabJack and streaming, and you'll have a streamlined control loop.

 

[Jimmy1125]

Thank you. I will try that. As for the tooth count, I’m a lot slower than 3000 rpm. I’m running through a 25/1 gearbox and a vfd, which is controlled by the LJTicDAC. 

[Jimmy1125]

Just to be clear, when you put startStream(), are you meaning to put the actual streaming commands? Same with bdc(). 
Instead of starting my stream sequence, you want me to put in the commands from that sequence directly in cvpplot. 

[AzeoTech]

No.  I mean calling the sequence as a function.  The syntax is exactly what I provided.  So:

startStream()

will run the code in your startStream sequence as if it was pasted into your calling sequence.  See 5.17 in the user's guide, or check out any intro programming text on functions.  They are a powerful tool that I think will help you in many ways as you progress.