How to get complete array out of a for loop and plot it after each iteration?

[ASH2020]

Thanks altenbach.

This is a different type of averaging. It's not a boxcar or moving average to smooth one dataset as your example shows. It's more like averaging multiple curves in Matlab. The same test is repeated 10 times, producing almost the same curve of 40 points each time. Curve 1 and curve 2 are averaged together, (not along themselves) then curves 1, 2 & 3, then 1,2,3 & 4, and so on. Each time a dataset comes in (every 1/2 second), the same curve improves until the 10th is the best. the problem I had was plotting each curve as the loop was running, but it works nicely now.

[altenbach]

---

@ASH2020 wrote:

Curve 1 and curve 2 are averaged together, (not along themselves) ...

---

I have no idea what that even means! (What is the difference between "together" and "themselves"??)

My code shows how the signal improves with each iteration, showing the average of the previous N signals at each iteration. How is that different to what you are trying to do? Did you try my code?

If you want to average the last N samples of an experiment that goes on forever, you would need to store N signals in a 2D array, of course.

[Blokk]

---

@altenbach wrote:

---

@Blokk wrote:

---

Hmm, i think the two waits are not parallel, so they will add up. But i will benchmark it, when i get to my PC 🙂

---

Except for dataflow constraints, all waits run in parallel. There is a 100ms wait inside the sequence frame, a 500ms wait in the toplevel diagram of the big FOR loop. (And a 2ms wait inside the 40x FOR loop (80ms total) which makes absolutely no sense). If the others can finish in under 500ms, the total loop time will be 500ms. (See also this discussion)

---

Thanks for the clarification! I will keep this in mind!

[ASH2020]

Hi, it looks like your code is a standard "boxcar" where you would pick an average coefficient, say 3, then you average points 1,2,3 then average points 2,3,4, then average points 3,4,5 and so on "along" the curve, which gives a smoothing of the dataset. Like this:

Mine averages all the point 1s on curves, then all the point 2s, etc. Like this:

Hope this makes sense.

[ASH2020]

Hey Blokk,

Just to explain the waits, the 100ms is between the Visa write and Visa read. I found this by experimentation, any shorter than about 70ms and it crashes. The 2ms was purely for development, so I could see the loop count with an indicator. Otherwise it runs so fast you can't see it happening. It've taken it out now. The 500ms sets the time for acquisition of data packets. It is bang on 5 seconds for 10 loops.

[altenbach]

---

@ASH2020 wrote:

Hi, it looks like your code is a standard "boxcar" where you would pick an average coefficient, say 3, then you average points 1,2,3 then average points 2,3,4, then average points 3,4,5 and so on "along" the curve, which gives a smoothing of the dataset. Like this: 

---

You need to quote relevant parts of the post you are replying to, else nobody knows what "your code" refers to. My code certainly does not do what you describe here. My code shows the following at each iteration on the second plot:

1. scan 1
2. average of scan 1&2
3. average of scan 1, 2, 3
4. average of scan 1, 2, 3, 4
5. average of scan 1, 2, 3, ..., 5
6. average of scan 1, 2, 3, ..., 6
7. average of scan 1, 2, 3, ..., 7
8. average of scan 1, 2, 3, ..., 8
9. average of scan 1, 2, 3, ..., 9
10. average of all 10 scans

[Blokk]

---

@ASH2020 wrote:

Hey Blokk,

Just to explain the waits, the 100ms is between the Visa write and Visa read. I found this by experimentation, any shorter than about 70ms and it crashes. The 2ms was purely for development, so I could see the loop count with an indicator. Otherwise it runs so fast you can't see it happening. It've taken it out now. The 500ms sets the time for acquisition of data packets. It is bang on 5 seconds for 10 loops.

---

Hmm, in principle, if the serial protocol of your device uses a proper termination character, you do not need a Wait between the VISA Write and Read. The VISA Read will just wait automatically until a data string arrives with a termination character at the end. As I see in your first post VI, you left the termination character unwired, thus keeping the default xA value. Does your manual of the device state what termination character should be used? Either, I do not see the "Build Data Packet.vi" content, how you form the serial request.

Actually just recently I worked on a driver for a serial device, and using a proper termination character, I did not need any Wait between the VISA Write and Read. However, the device "did not like" polling: I needed to add a 100 msec wait after each Write/Read sessions...So in the end I needed a Wait anyway 🙂

[ASH2020]

My apologies altenbach. In that case I misunderstood. Thank you for the example.

[ASH2020]

Blokk, we haven't got a termination character in the data request at the moment. The hardware is our own and has different parts, each with an ARM processor, running a Forth kernel. The data packet sent from the GUI has an address, an event, various time elements, packet length, a bit of other stuff and a checksum. The main ARM then routes the packet accordingly to the other ARMS via I2C and something then takes place, which then provides the return packet. So, there may well be a delay in the equipment itself. We're so flat out getting everything going at the moment that there hasn't been the opportunity to look into timing in great detail. I have my doubts that it is to do with the serial bus, but one day, when there's time, I will investigate. (Yeah, and pigs might fly!)  Thanks for all your help with it.

[Blokk]

---

@ASH2020 wrote:

Blokk, we haven't got a termination character in the data request at the moment. The hardware is our own and has different parts, each with an ARM processor, running a Forth kernel. The data packet sent from the GUI has an address, an event, various time elements, packet length, a bit of other stuff and a checksum. The main ARM then routes the packet accordingly to the other ARMS via I2C and something then takes place, which then provides the return packet. So, there may well be a delay in the equipment itself. We're so flat out getting everything going at the moment that there hasn't been the opportunity to look into timing in great detail. I have my doubts that it is to do with the serial bus, but one day, when there's time, I will investigate. (Yeah, and pigs might fly!)  Thanks for all your help with it.

---

I see! 🙂 Anyway, if the RS232 comm works stable with that 100 msec wait, just do not touch it! 😄