From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Sorensen XG 60-14 error

Solved!
Go to solution

Hello,

 

I have a problem with a recently purchased Sorensen XG 60-14 programmable PSU. In my application (LabView 2012) I use this psu to supply a Peltier cooler via PID control. My code sets the output current of the PSU at every 1 sec. My application runs without any problem for days, up to like 4-5 days, and then I get a crash.

The first problem is that, when I get error, the LabView gives a pop-up window asking whether continue or stop? This is really not good, since my code should totally stop in case of error (i wrote my code in a way if there is error, it should close and stop all other equipment, like other PSUs). I have used the Sorensen official "lvlib" to make my own VIs, see them attached in the zip file.

 

In my code, first I tried to use the "Configure Output.vi" official Sorensen VI with very small modification, but usually I got errors and crashes after 2-3 days. Then I decided to get rid of the flat-sequence-structure, and also I do not need to Enable the output at every current set, so I sorted this out too.

Now I use the "Configure Output_Sorensen_XG.vi", and I call it from the "Sorensen_XG_psu.vi". So in my top level VI, I call these VIs with 1Hz rate.

 

First I insert here the photo of the first error which I see as a pop-up error window:

Sorensen_XG_error_mod.jpg

 

After clicking on "continue", I get the following error, but I guess the above first error is the relevant one, since the next one is generated because of the closed resources?

 

Sorensen_XG_error_mod2.jpg

 

What can be the problem? Did I create memory leak somehow? Should I close certain refnums in the "Configure Output_Sorensen_XG.vi" after every iteration, there are quite a lot property nodes...?

 

I hope someone can help me...thanks very much!

 

EDIT:  actually I have realised that, the second jpg is the relevant error info, since the first one is just an error from a subVI, where I try to close PSUs in case of error, and that part is not connected via error wire.

So the relevant error is second, the "refnum zero or deleted" one. But how the refnum becomes null?...

0 Kudos
Message 1 of 33
(3,550 Views)

So the original subVI is this:

 

subVI_original.jpg

I wonder if the problem can be that, I do not close the refnums, so I modified the VI in this way:

 

subVI_new.jpg

 

 

I started my application now, lets see if I get error again, or not...

Any suggestion is welcomed!

Thanks!

 

0 Kudos
Message 2 of 33
(3,520 Views)

You need to show the VI that has you changing the current every second.

0 Kudos
Message 3 of 33
(3,512 Views)
I had no luck getting the IVI-C driver to work. Never tried the IVI-COM you are using, though. After a couple of hours, I just wrote a LabVIEW driver starring with the wizard. Done in about half a day. Something to consider. Power supplies are pretty trivial to control.
0 Kudos
Message 4 of 33
(3,508 Views)
The calling vi is also in the zip file. Above that nothing relevant: the pid gives a new current value at every 1 sec...
0 Kudos
Message 5 of 33
(3,502 Views)

@Blokk wrote:
The calling vi is also in the zip file. Above that nothing relevant: the pid gives a new current value at every 1 sec...

I am not seeing code where the output current is being changed every second.

I see configuration.

 

Edit:  Anyway, I see three references that are not being closed in the Configure Output_Sorensens_XG.vi

0 Kudos
Message 6 of 33
(3,496 Views)

Hello, my top VI is very big, and also contains some data which I would not like to share to public. Anyway, basicly I have a while loop which iterates at every sec. Before the while loop, I use the "Sorensen_XG_psu.vi" (this VI includes the "Configure Output_Sorensen_XG.vi") with the mode input tunnel set as "init".

 

Inside the while loop, I have a PID calculation VI (from PID toolkit) which output is connected to the current input terminal (set current (A)) of the "Sorensen_XG_psu.vi".

Here the mode input tunnel is always set (with constant) as "set_current".

Of course, if I shut down my app, after the while loop I set the mode to "stop".

 

 

Edit:  Anyway, I see three references that are not being closed in the Configure Output_Sorensens_XG.vi

 

 Actually I only see two references: "Outputs" and "System". The reference called "AmetekXGLib.IAmetekXG" comes in as an input tunnel, and also goes out as output tunnel as you see. When I call the "Sorensen_XG_psu.vi" in init mode, I get this ref, and afterward I just store it in a shiftregister as you see...

 

So the modification as you see in my post above is that, I close down the refs "Outputs" and "System" at every iteration...Now my application is running, lets see for how long...This application is controlling a measurement which must run for weeks, so an error after a few days is not acceptable...

 

Thanks for the help,

Best Regards,

 

0 Kudos
Message 7 of 33
(3,487 Views)

I have never had good luck using any IVI drivers.

 

Here is my Sorenson SG series SCPI vi set.

========================
=== Engineer Ambiguously ===
========================
0 Kudos
Message 8 of 33
(3,482 Views)
Solution
Accepted by topic author Blokk

@Blokk wrote:

 Actually I only see two references: "Outputs" and "System". The reference called "AmetekXGLib.IAmetekXG" comes in as an input tunnel, and also goes out as output tunnel as you see. When I call the "Sorensen_XG_psu.vi" in init mode, I get this ref, and afterward I just store it in a shiftregister as you see...


 


1.) IAmetekXGOutputs

2.) IAmetekXGOutputChannel

3.) IAmetekXGSystem

4.) IAmetekXG - which you are reusing via shift register

 

Unclosed references cause Excel to remain running in the background which is why I notice them.

 

 

Message 9 of 33
(3,472 Views)
The IVI-COM driver seems an odd choice to begin with. As much as I dislike IVI-C, the IVI-COM approach is at least an order of magnitude worse.
0 Kudos
Message 10 of 33
(3,469 Views)