Problème de continuité de cadencement d'une sortie logique

[btsmci.saumur]

Bonjour

Je cherche à piloter une sortie logique "OSI" cadencée en continu par un top tour codeur (à une fréquence constante de 15 Hz).

La boucle "Calcul de l'avance" me permet de modifier le temps d'attente initiale de "OSI" (j'ai simplifié le contenu de la boucle pour la compréhension, le calcul de l'avance est à la base beaucoup plus complexe) par l'intermédiaire de la structure événement présente dans la boucle "gestion temps d'attente" avec une variable locale.

A la base le système pilote 3 sorties logique avec 2 conditions "valeur changée".

Le Vi fonctionne correctement mais j'ai une interruption de la sortie OSI de 3 tops toutes les secondes (à chaque rafraîchissement de la boucle "Calcul de l'avance" et pas uniquement à l’événement de la structure événement (valeur changée de "tps attente").

Je cherche à obtenir un fonctionnement sans interruption des sorties logiques.

J'imagine pouvoir :

- limiter le nombre d'interruption de la voie OSI, uniquement quand "tps attente" change de valeur.

- diminuer le temps de lecture de la variable locale "tps d'avance" afin de diminuer le temps d'interruption pour éviter de perdre de tops.

Cordialement

Yannick

[GerdW]

Hi Yannick,

---

@btsmci.saumur wrote:

I am trying to drive an "OSI" logic output clocked continuously by an encoder pulse (at a constant frequency of 15 Hz).

The "Advance calculation" loop allows me to modify the initial waiting time of "OSI" (I simplified the content of the loop for understanding, the advance calculation is basically much more complex ) via the event structure present in the "waiting time management" loop with a local variable.

Basically, the system controls 3 logic outputs with 2 "value changed" conditions.

The Vi works correctly but I have an interruption of the OSI output of 3 ticks every second (at each refresh of the loop "Advance calculation" and not only at the event of the structure event (value changed from " wait time").

I am looking to achieve uninterrupted operation of the logic outputs.

I imagine being able to:

- limit the number of OSI channel interruptions, only when "waiting time" changes value.

- reduce the reading time of the local variable "advance time" in order to reduce the interrupt time to avoid losing ticks.

---

Your "advance calculation" loop iterates just once per second, so how do you get "3 ticks every second"?

Where do you notice those "3 ticks"? (What are "3 ticks"?)

Why is your timeout event to wait just "0 ms"?

Why do you need a local variable at all, when you can use the "new value" from the event structure input node?

Why do you think the local variable will be "reading slow"?

See this:

[btsmci.saumur]

Thank you for your answer.
Here is my complete VI
I increased the number of sub-diagrams in order to use correctly the new value (only one event condition by sub-diagram)
I also increased the timeout.
I still have the same problem of interruption of my logical outputs.
Attached :
- the event log in which you can see the interrogation phases of the changed values,
- the oscilloscope reading of the encoder top tower in channel A and of the "OSI" output in channel B. We can see the loss of 2 tops (and not 3 as said in my previous message) at each interrogation of the changed values.
Sincerely
Yannick

[GerdW]

Hi Yannick,

---

@btsmci.saumur wrote:

I still have the same problem of interruption of my logical outputs.

---

You are stopping and starting the DAQmx task. You do that twice in two event cases. You call both events, one after the other.

What else do you expect, when you switch off any output?

Can't you change those properties in just one event?

Can't you change those properties without stopping the task? (I don't have hardware at hand to test that…)

On your VI:

• I REALLY recommend to cleanup and to use subVIs.
• Hiding event structures inside case structures is NOT recommended practice.
• P_abs and P_adm are measured using the very same AI channel with the very same scaling: one of them shows "bars" and the other "mbars"? How is that possible?

[btsmci.saumur]

After testing, here are some answers :

What else do you expect, when you disable an output?
Can't you change these properties in one event?

I have 2 parameters driving the actuators, ALL (+OSI) and INJ. We will have to change either one or the other.

Can't you change these properties without stopping the task? (I don't have any hardware at hand to test this...)

I tried this, and it doesn't work. Changing a task property requires the task to be stopped to take effect.

On your VI:
I REALLY recommend cleaning up and using subVIs.
Hiding event structures inside case structures is NOT a recommended practice.
P_abs and P_adm are measured using the same AI channel with the same scaling: one shows "bars" and the other shows "mbars"? How is this possible?
This is a mistake on my part. It is Pambiante (not abs) in mbars, which I memorize before starting the engine.

If I do the assessment:
With the 1st Vi of my 1st message (simplified Vi), the fact of using the "new value" makes me lose only one top (against 2 for my complete model).
If I put a "mouse released" event on a button, I almost solve the problem (I only lose a top when I press this button).
The problem is that I also try to regulate my logic outputs with parameters that vary according to information from sensors.

Sincerely
Yannick