programs hangs, unless highlighting execution or disabling multithreading

[Anthony_de_Vries]

I'm making a program to control my signal generator over a GPIB board. Have all the drivers belonging to the SG, so it's just a simple loop where I can set the parameters. VERY basic, I thought....

The program almost immediately hangs... However, when I use 'highlight execution', or 'single step' through it, it runs fine. No problems at all. So that makes it a bit difficult to debug... 🙂
Been testing a lot allready and found out that disabling multithreading also solves the problem.

Does that sound familiar? Any way to solve the problem?
I guess it's a timing problem of some sort, but I'm not sure that I can change much. I'm almost only calling the SG driver VI's. Looked into those VI's, and they're all just DLL calls. Nothing I can do there...

Ofcourse I could just disable multithreading as a work-around. But how bad will I suffer in performance/responsiveness if I disable multithreading? It's only a tiny program now, but it's supposed to grow quite big.

Any thoughts?

[alkazaa]

---

@Anthony de Vries wrote:
...Have all the drivers belonging to the SG...
...I'm almost only calling the SG driver VI's....they're all just DLL calls. Nothing I can do there...

---

What brand is your SG? Since the drivers you have are not written in 'LabVIEW', but DLLs, it is indeed difficult to debug. Did you try to find a REAL LabVIEW driver for it? If you can tell us the SG's manufacturer, someone might be able to point you to a generic LabVIEW driver (and you would very probably not encounter any of those problems)

[Ben]

"It's only a tiny program now, but it's supposed to grow quite big."

I understand your concerns!

I do not have to time to go into the details but I will through out some hints.

1) DLL calls will (by default) run in the User interface thread. If possible, you may want to configure the calls to execute in different threads (The dll must be thread safe, etc...)

2) A few strategiclly placed "waits" can prevent CPU abuse.

Ben

[Anthony_de_Vries]

Thanks for all the suggestions.

Been trying them out. Reconfigured the VI´s to run in the ´Instrument I/O´ thread. That didn´t help yet.

Now I´ve placed a 100ms 'wait' after each instrument call, and that seems to have solved the problem. I guess the DLL itself is not thread safe...

I´d better make a wait VI that has an error in and out. My VI looks a mess now, with all these flat sequences. 🙂

BTW: The instrument is an Marconi 2030 RF signal generator, connected with GPIB. Driver IFR-20xx. Downloaded the driver from the NI site... I think I´ll drop them a mail describing the problem and solution.

[Albert.Geven]

Your problem can be genrated by too fast messaging to the SG
Also polling on a statusbyte should not be too fast, but ms waits should not be neceesary except
when polling in a while loop.

Using sequences to determine execution order is the second best.
Error In, Error out offer better control and more readability.
Parallellisme can be maintaind by using merge errors to synchronize two parallel lines.

Anyhow for IO you should use errorIO to prevent that the first IO-error is swept under the carpet.

[Anthony_de_Vries]

---

@Albert Geven wrote:
Your problem can be genrated by too fast messaging to the SG
Also polling on a statusbyte should not be too fast, but ms waits should not be neceesary except when polling in a while loop.

---

Not sure that I understand.. Do you mean that the VI´s that control the SG allready return before the actual instruction is carried out by the instrument? So that I´m issuing new commands while it is not ready with the first ones?

---

Using sequences to determine execution order is the second best.
Error In, Error out offer better control and more readability.

---

I know, I know.... But the standard Labview 'wait' VI doesn´t have error I/O. So when I quickly needed to put a wait in a specific spot, I added a sequence around the wait, and run the error line through it. Just now that I had to put in so many, it was becoming a mess. Allready made a custom 'wait' VI with error lines now. (See the code)


Greetings from Germany. 🙂

[Albert.Geven]

There is a wait with error Io in the NIDAQ counter utilities

it is called "C:\Program Files\National Instruments\LabVIEW 7.1\vi.lib\DAQ\CTR.LLB\Wait+ (ms).vi"
and I use it a lot.
It has nothing to do wit NIDAQ and is awfully deep buried in the palette

[Dennis_Knutson]

Besides the Wait function that Albert mentions on the DAQ palette, there is the Time Delay Express VI introduced with LabVIEW 7.0. It has error in/out connections.

[alkazaa]

You might want to try the driver 'IFR203x'. It does not use any DLL, as far as I've seen.

[Anthony_de_Vries]

I've switched to the IFR203x drivers, and they work flawlessly.


Thanks all!