Vider buffer

[Diallo_td]

la carte c'est plutôt une daqcard6024e.

[GerdW]

Hi Diallo,

we are missing all subVIs and globals.

Please provide the full project!

(Hopefully you organized the code within one folder: ZIP that folder and attach the ZIP.)

[Diallo_td]

attached the zipped file with all the sub-screws including the old ones used for the configuration

[GerdW]

Hi Diallo,

thanks for posting the full code…

---

@Diallo_td wrote:
When I remove the vi generation from the outputs, I speed up the display but the program does not show me the real signal. I need to speed up the program to make a real time display. There it is really a problem of buffer, I made all that is prescribed in this forum in particular the size of the buffer, the sampling frequency, the number of points, for the moment nothing.

---

Some observations:

• Is there a reason to use SGL data in your tool? When switching to DBL (arrays) you will reduce the number of coercion dots and several (array) conversions…
• By removing some "bad constructs" you might improve execution speed of VIs, like using autoindexing output tunnels in loops instead of building arrays using a shift register and BuildArray! (Seen in "changement de fréquence d'échantillonnage")
• You really should organize the whole code in a LabVIEW project, LV2009 already supports that!
• In your "generation des sorties" case you always create a new continuous AO task: wouldn't it be better to create the task once and use it several times?
  Edit: found other occurences of the task global: there's a lot of array manipulation going on, and always with coercion dots…
• It seems you try to add some new functions to this old tool - which is quite hard due to the code setup…
  Instead of fiddling in this state machine I really would restart the whole tool from scratch with a clean algorithm/concept. I see the tool is very old, written using very old (and nowadays hidden) functions and lots of globals: try to implement modern (even in terms of LV2009!) constructs!
• Don't forget to use a SCC tool (or regular backups) before starting to change code…
• How do you convert to GMT by adding multiples of 23 hours (in ConversionGMT)?
  

[Diallo_td]

In fact, the old program.
there are the old screws in the subroutines for configuration and writing. We changed them to use the ni-daq.
I didn't make the original program, I'm new to labview

[Diallo_td]

This VI converts a time so that it can be displayed in hours:minutes:seconds format. Indeed, when converting a time in seconds to the “date/time” format, LABVIEW considers this time as the number of seconds elapsed since January 1, 1970, 0:00 a.m., universal time. However, this time is displayed taking legal time into account (configured in WINDOWS). In other words, in Paris, 0 s will be converted into 1 h 00 min in winter and 2 h 00 min in summer (the date here is not important).

To avoid this, this “excess” number of hours (obtained precisely by converting 0 to the “date/time” format) will be subtracted from our time in order to find 0 h 00 min for a time of 0 s. However this new time will be negative and to be able to be converted, it must be positive. So rather than subtracting 1 h or 2 h, we will add 23 h or 46 h (i.e. 23 h, i.e. 82800 s, multiplied by the number of hours to be subtracted).

This new value should only be used for display purposes as it no longer corresponds to real time in seconds.

[GerdW]

Hi Diallo,

---

@Diallo_td wrote:
This VI converts a time so that it can be displayed in hours:minutes:seconds format. Indeed, when converting a time in seconds to the “date/time” format, LABVIEW considers this time as the number of seconds elapsed since January 1, 1970, 0:00 a.m., universal time. However, this time is displayed taking legal time into account (configured in WINDOWS). In other words, in Paris, 0 s will be converted into 1 h 00 min in winter and 2 h 00 min in summer (the date here is not important). To avoid this, this “excess” number of hours (obtained precisely by converting 0 to the “date/time” format) will be subtracted from our time in order to find 0 h 00 min for a time of 0 s. However this new time will be negative and to be able to be converted, it must be positive. So rather than subtracting 1 h or 2 h, we will add 23 h or 46 h (i.e. 23 h, i.e. 82800 s, multiplied by the number of hours to be subtracted). This new value should only be used for display purposes as it no longer corresponds to real time in seconds.

---

The LabVIEW epoch is 01.01.1904 (12:00 a.m.)!

The whole problem originates from using that old code: by implementing new routines using the LV2009 features you can rather easily correct relative times or handle DST (DaylightSavingsTime)!

That's one reason why I suggested to restart the whole project…

[Diallo_td]

restart all project will be very difficult for me,  i don't have a lot of time, we must arrange that soon.

I think there are way to arrange that without restarting all the project.

[GerdW]

Hi Diallo,

---

@Diallo_td wrote:

I think there are way to arrange that without restarting all the project.

---

The hard part is to understand

• how the VIs and the measurement system work
• how to change things in the VI without messing with existing algorithm/timings

Once you solved both items (with creating good documentation) you may start with changing the VI(s)…

---

@Diallo_td wrote:

i don't have a lot of time, we must arrange that soon.

---

Then you better get some co-workers with a lot of experience regarding this measurement setup!

And involving someone with more LabVIEW experience might help, too…

[Diallo_td]

In fact this program is a modification of the old one which used the old measurement screws (AI config, Ao config, AO write and read), I think there is a possibility of managing the problem by reworking the output Vis config and output generation. The program is far away, if it's all over again it's going to be something else.