Sending commands to Power Meter. Based on producer / consumer structure.

[mrspock]

Hi 

I am creating software for testing products under high temperature. Now I am stuck on sending commands to Power Meter Yokogawa 2030. For faster analysis I prepared two programs "mainProgram_not_working" and "mainProgram_working".

My first idea is to load steps from .txt file (included in project "Software") where each line have 2 information. Before "_" is info to choose case e.g. go to "meter" case, and after "_" what need to be done in this case "meter" e.g. "MEASURE:ITEM:NORMAL:V:ELEMENT1 ON"

If I am putting this info like in "mainProgram_not_working" the program crashesch and I need to restart LabView. I do not tell you what is an issue because it is hard to debug this.

After modyfying program "mainProgram_working" and not load info from .txt file, but have it in "meter" case it works ok. The power meter gets all values corretly.

Also I made testing version "stressTest_description of steps" to chceck how this commands goes to power meter but i did not find anything wrong.

So if someone can show me or give some hints what to chceck please do :-). I know this can be difficult without power meter hardware, but meybey more experienced user can take a look 🙂

[mrspock]

Using LabVIEW 2020 SP1 64bit

[RTSLVU]

---

@mrspock wrote:

Using LabVIEW 2020 SP1 64bit

---

I do similar testing with a Yokogawa power analyzer almost daily.

What I do is instead of requesting individual measurements one SCPI command at a time. (have you looked for LabVIEW drivers?) I send a measurement list to the Yokogawa and have it continuously taking measurements at 100mS intervals (Fastest update rate). Then I just log the most recent measurement as needed. This also give my program the ability to constantly monitor the test and shut everything down if the UUT enters an unsafe operating condition.

I took a look at your main program, it looks like you are trying to make a "Queued State Machine" not a Producer/Consumer.

[mrspock]

RTSLVU thanks for response. I do not find any drivers for WT2030. Abot yor solution, I never think to do it like you did, meybey it will work for me too. I need to consider this :-). Rearding to my program, still I think that is Producer/Consumer pattern. Meybay combination of State Machine and Prodducer Consumer pattern.

Regards

Dawid

[RTSLVU]

---

@mrspock wrote:

RTSLVU thanks for response. I do not find any drivers for WT2030. Abot yor solution, I never think to do it like you did, meybey it will work for me too. I need to consider this :-). Rearding to my program, still I think that is Producer/Consumer pattern. Meybay combination of State Machine and Prodducer Consumer pattern.

Regards

Dawid

---

Well... In reality even the Producer/Consumer architecture is a State Machine at its core...

But what I see here is your "producer" is just loading a Queue with states to run in the "Consumer" loop.

That's a Queued State Machine.

A producer Consumer is used when you need the Producer to take high speed measurements and queue them up so the Consumer can take it's own sweet time dequeuing and processing the measurements.

[mrspock]

Ok, now I get your point, you have right. 🙂