Running Reentrant vi on rt

Whenever i try to run a(particular)reentrant vi on the RT target some unusual behaviour results
Giving the error from the rt that connection to the target has been lost. Moreover someother vi's are also reentran but those vi's
run perfectly. Can anyone please help me

It may be related to memory allocation. Here is a related thread. Or, you may just be crowding out normal priority threads because your higher priority thread never sleeps. Here are some great resources on timing and multithreading:
Multithreading in LabVIEW Real-Time
Timing Deterministic Applications (RT Module)
Also the NI Real-Time Execution Trace Toolkit can help you troubleshoot this issue if you are indeed starving your normal priority thread.
Let us know how it goes. If none of this material proves helpful, can you provide some additional information about the nature of you application and any specific error messages you are receiving?
Message Edited by David_B on 02-27-2008 10:16 PM
David_B
Applications Engineer
National Instruments

Similar Messages

Does "Run VI" invoke node work on strict references to REENTRANT VIs?

I am using LV 6.02 on Windows 2000.
I am trying to use the "Run VI" invoke node method with a reference to a Reentrant VI, with no success. (It works when VI is not reentrant. Perhaps there is a reason this cannot work. But if not, I wonder if there is a workaround, or if LabVIEW 6.1 has a fix?
Hopefully the picture of the block diagram I included is sufficient...but I also included the actual code just in case.
Thanks!
Steve
Attachments:
block_diagram.jpg ‏66 KB
Parent_VI_Example.vi ‏43 KB
Prototype_subVI_shell_for_Simplex_Fit.vi ‏40 KB

Hi, Labviewguru,
Thanks for taking the time to look at my admittedly messy (flawed) block diagram. I will try to state my ultimate goal:
You may be familiar with Levinberg-Marquardt nonlinear curve fit in Labview, which is about 5 VIs in a LLB file. In order to change the type of curve fitting, one has to either modify a formula node in the lowest subVI (Target Func and Deriv), or place a different subVI in there. That's fine until I want to have many different sorts of algorithms.
What I was thinking of doing is instead passing Target Func and Deriv a reference to the VI which would perform the calculations. This would allow me to use the same fitting code to fit different types of data with substantially different methods--without modifyin
g the low-level fitting code at all.
I'm not sure this is going to make any sense to you, but thanks again for your help.
In regards to your answer above, let me clarify somewhat. I had the call by reference node in there to prove that the reference to the VI was "good" and worked fine...this same reference was passed to the invoke node, which didn't have any apparent effect.
Also, I don't think the path to the VI I am opening the reference to is redundant. It is required to tell the "Open VI reference" which VI to load.
I agree that using references to pass values around is not generally a good idea: I was using that method for my supposed versatility in the future.
Thanks,
Steve

How do I run a reentrant VI.

I have a VI that I am running to test firmware in a satellite modem. The next task is to develop a top level VI that will run this VI in three different instances. I am trying to come up with a way to do it and it is not trivial which is why I am on here looking for some advice. I have been messing around with queues to queue up the tests based on what buttons are pushed on the front panel. Basically for this discussion I want to be able to run the test at max three times simultaneously. I know the best way is probably to use the VI in Test Stand but I am trying to see if it is worth while basically making a test executive in Labview first. Any advice would be appreciated.

Hi trosier,
If you go down the do-it-yourself reentrancy road, here's a utility for you. During debug it's tempting to turn reentrancy OFF, but possibly catastrophic to leave it that way. In a system with many reentrant VIs, it's too easy (for me) to loose track. After my first (and only) reentrancy nightmare, I made this VI to check/set the reentrancy of an array of VIs. I think it was helpful, but a bit of a pain to keep the list up-to-date during rapid-prototyping. It's not especially complicated, but may save you some time. NOTE: This VI had one error-message-related sub-vi which I've [just] stripped-out for simplicity...
Cheers.
Message Edited by Dynamik on 06-01-2006 02:12 AM
When they give imbeciles handicap-parking, I won't have so far to walk!
Attachments:
Util.VI.ReentrantCheck.vi ‏63 KB

How to find vi reference to reentrant vi running

I launch some compy of a reentrant vi that run untill the caller vi stop it setting the STOP button trough an invoke node at "set control value".
If i abort the executioin of the caller vi how can i retrive the reference of the running vi to stop them?

You will need to create a cache of references to the Reentrant VIs when you launch them. You are using VI Server to launch them, right? This means that you have access to the references at the time of instanciation, so you can create a tool (queue or something) that stores a copy of the refnums.
Good luck,
-Jim

Can I use SubPanels to display and run multiple executables from the same GUI?

I have two Labview executables that performs some A/D I/O, each using an independent USB-6008. I would like to run both of these executables from a single UI. Is this possible usin SubPanels? Or some other method?
I found KB regarding exe's and VI Server but can't seem to get the suggested workarounds implemented.
http://digital.ni.com/public.nsf/allkb/8545726A00272EB0862571DA005B896C?OpenDocument
I am using Labview2009
Thanks
Dan
Solved!
Go to Solution.

DBerry wrote:
No, of course I am not sure yet. I have only begun testing this method.
Not sharing common hardware (separate USM-6008s).
Here is the whole picture:
I have developed a top-level VI that performs Daqmx IO using a single USB-6008. The top-level VI references a Project Daqmx Task that points to the desired 6008. I would like to create a single UI that uses this top-level VI to control twoUSB-6008s simultaneously. I thought I could build the top-level VI into 2 separate exes, where the only difference between the exes is the hardware it points to (one exe to each of the 6008s). But I have been unsuccessful at running these two exes within a single UI. I attempted use subpanels on a tab control to do this but I am unable to obtain a reference to the top-level vis once they have been built into an exe. I have also tried building a dll and exporting the top-level vi from the dll build but i can't seem to get that to work either. In both of these cases my Open VI reference function returns errors (Error 1445). I am aware of the changes in referencing VIs from within an exe/dll since LV8.2 - http://digital.ni.com/public.nsf/allkb/8545726A00272EB0862571DA005B896C
The link seems to suggest that I should be able to obtain a reference to the top-level vi within the dll but I can't get it to work.
So I then moved on to the above method (making all the subvis reentrant). I just haven't figured this all out yet.
If you have suggestions on other problems I may run into please share. I think I can eliminate my FGs but haven't gotten back to this yet.
Thanks
Dan
When I am designing apps of the type you described I have kept the ned goal in mind from the begining since of the issue you are mentioning. I also don't want to tell you to throw it all away and start over. So with that in mind I have been looking at your posts and only offering the least destrutive ideas first. With that in mind I would like to invite yo uto look at the code i posted in this thread (reply #18 has a zip).
That code shows how to realize un-dockable GUI regions but it passes the ref of the top level VI to a reentrant VI it instanciate for each undockable region. It may have enough hints and technique to give you some ideas that will work for you.
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

Visa Read Timeout Occurs with multiple Reentrant VI Calls

I have written a test application in Labview (6.1) which will be used to test (burn-in) up to 15 serial instruments through a 16 Port USB->RS232 Hub. Here's how it works:
When the App loads, I am transmitting a Connect command to each of 15 com ports (one-at-a-time) using VISA. If I receive the proper response from the unit on that port, I add the port to an array and continue on to the next system. Once I've found all systems on the hub, I wire my array of active Visa references to a for loop in which I open up to 15 reentrant VIs which will run in the background in parallel. Each of these reentrant VIs (all are idential with the exception of the Visa Resource they use) running in the background are sending commands to the the respective instrument and receiving a response. One Function in particular "Get Unit Status" is important and the response determines whether or not the instrument is functioning correctly. Here's the problem -- In my Main Loop, I am continuously acquiring indicator values from each of the reentrant VIs that are running in the background. After a period of time (not consistent) I will lose communication with a port (the symptom is no response from the unit). I've looked closely at the COMM engine I created and found that the Visa Write function is completing without error, then when I perform a Visa Read I immediately get the "Timeout occured before operation completed" error (please keep in mind that this occurs after 100-5000 successful attempts at writing/reading). Eventually another port will drop out, followed by another. This seems to stop occurring and the remaining systems run to completion without a problem.
Some background on what how I'm setting up my Visa Sessions...
When I originally scan for systems (before I load and run the Reentrant VIs)
- Init Visa Port
- 19200, 8, N, 1
- Use Termination = True
- Timeout = 400mS (I've tried larger values already) 400mS should be plenty
- Termination Char=13 (/r)
- Open Visa Session
- Visa Write "CONN18/r" (the command required to connect to my instrument)
- Visa Read with 1 for requrested byte count to read 1 byte at-a-time, concatenating the results until /r is received (or 1000mS timeout occurs -- this is not a VISA timeout) I've also tried 16 for requested byte count and just waiting for Visa to timeout -- both methods work.
Once all 16 ports are scanned I Close ALL of the ports using the Visa Close Function.
It is important to know at this time that I "AM" using proper wiring flow to ensure open occurs before write, write occurs before read, etc.
I'm assuming at this time that all of my Visa sessions are closed.
On to the Reentrant VIs:
Inside each reentrant VI I first Initialize all of my variables and Init/Open a 'New'? Visa session using the same parameters mentioned above.
Then I enter the "Run" case structure where all of the communication begins.
I am using the same Communications Engine to operate the instrument as before (the only difference being that all of the VIs in the comm engine are now reentrant and operate at higher priorities) I have actually saved two different versions of the engine (one for the reentrant calls and one for when I first scan for systems from my Main GUI).
When I init the reentrant VI, I am placing the Duplicate Visa Resource output of my Visa Open Function on a shift register. When I enter the Run case, it takes the Resource from the register on the left, wires through any Comm Engine Vis then back out to the shift register on the right and keeps going for a 12-hour period or until "Get Unit Status" has returned 60 naughty results.
On my Main GUI I am continuously (every 500mS) I am Getting certain Indicator Values from each reentrant VI AND I am also setting some control Values on each reentrant VI. There is no VISA interaction between each Reentrant VI, and the Main GUI.
As I said earlier, up to 15 systems will run for a time, then one will stop responding, followed by another, and another until a few remaining systems will run to completion.
Any advice as to why I'm encountering the timeouts with the VISA read fucntion as I have metioned would be appreciated. I managed to find one suggestion which uses the Bytes at Port function to ensure there is data at the port before doing a Read otherwise, skip the read and retry the whole operation -- I haven't tried this yet.
Sorry for the wordiness of my question. If anyone would like some screen shots of portions of my code (I can't submit the actual code because some of it is confidential) I'd be happy to post them.
Doug.

Hi Doug,
The first thing I would recommend is the solution you have already found, to check and see if there is data at the port before attempting a read. I would be interested to see if this will solve the problem. Does there seem to be any trend to which ports have this timeout error? How many ports does it cut down to before operation seems to continue as expected? Does this number vary, or is it always the same number of ports? I think the best thing to do will be to identify constant attributes of how the error is occurring so that we can narrow it down and see what is going on.
John M

Error -18004; An error occurred accessing the LabVIEW Run-Time Engine DLL. TS 4.2.1 / LV 2010

When I try to run a VI that is reentrant in parallel execution, I receive this error. The details of the error is: LabVIEW: The property or method is not supported in this version of LabVIEW.
This is run under the Simple Operator Interface in LV 2010. The TestStand engine is version 4.2.1 using LV 2010 run-time engine adapter.
If I save for previous version to LV 2009 SP1 and set the TS adapter to 9.0.1 (2009 SP1), this works.
Can anyone reproduce this error (bug?) ?
Solved!
Go to Solution.

have you got the latest updates for TestStand using LabVIEW 2010?
http://digital.ni.com/public.nsf/allkb/7D728B70F167CE088625776E00582C7B?OpenDocument
Regards
Ray Farmer

How to run a do-while loop on the 2nd execution after a stop on failure occurs?

I am trying to use the Stop on Failure process model callback from the TestStand Examples.
If a step fails within a Do-While loop and the test is terminated, the second time the test is run (continuing to the Next UUT in the process model), the condition for the do-while loop is checked first before it ever enters the loop. This is incorrect because the Do-While loop should execute once and then check the "while" condition.
Also, If I was to stop the execution altogether and then restart the test (instead of continuing with the Next UUT), it runs the loop once, then checks the "while" condition.
I'm not sure if I am describing this clearly enough. The execution seems to flow like this:
Start test
Do
NumericTest step FAILS -> terminate
Next UUT starts
While (condition is false and skips over Numeric Test step).
So it seems that TestStand thinks it's still within that Do-While loop on the second execution and whatever runtime variables are not reset correctly.
Is this a TestStand bug? It happens in both TestStand 3.1 and 3.5.
Is there any way around this?
Thanks for any help.

If it is what I think it is, it is a bug. Try unchecking Sequence Properties>>Optimize Non-Reentrant Calls to This Sequence and please tell me if that fixes it.

How can you find out if another VI running on the same computer and how can you find out the name of that VI?

Suppose that several VIs running simultaneously on the same computer. How can I find out the names of the running VIs, from another VI?
If the already running VIs are clones of the same basic VI, open and run with the option "Prepare to call and forget", how can I find out the names and index of each clone?

I had an application where I spawned (= ran with Start Asynchronous Call) multiple (reentrant) copies of VIs, and would occasionally "lose control" of them. I needed a way to find all VIs that were running "Top Level" and stop them (so I didn't have to log off from Windows).
I used the Application Property "All VIs in Memory" to get an array of (wait for it ...) All VIs in Memory. I took each name, opened a VI reference to it (simply wire the name string in, as the VI is, by definition, "in memory"), looked at its VI Execution State, and if it was Run Top Level, Invoked the FP.Close and Abort VI Methods. [To prevent the VI that did all this from "committing Suicide", I compared the name string with the current Call Chain, and did nothing if there was a match].
I think you could adopt this idea to do what you need.
BS

Multiple instances of the same VI running in parallel

Hi,
I have a timestamping subVI that looks at a counter channel and applies timestamps. I want to create multiple instances of this subVI (8 to be exact) and have them all run in parallel (looking at 8 different channels). Someone gave me the following advice:
>>
Also, in case you want to call multiple instances of the same SubVI, and you want these multiple instances to execute in parallel, you will have to set the SubVI to execute in reentrant mode. Do this by opening the SubVI and going to "Edit >> VI Properties >> Execution" and enable "Reentrant execution".
<<
I've tried this but only my second instance (I started simple with only 2 instances) seems to monitor its channel and pass data along to the queue. I've included my code below, I have two signal simulators which simulate singles coming in on channels 2 and 3. I'm using a PCQI 6602 counter/timer card.
Any help would be greatly appreciated, thanks in advance,
Chris
Attachments:
LabView App (June 28, 2005).zip ‏158 KB

good news! Your reentrant VI is working and all three instances are running (as execution highlighting clearly shows). The problem is going to be an error that is occuring but you don't see because you are ignoring the error clusters internally in the timer. It looks like at one point it was set to quit if an error occurred. That still needs to be there.
Always hookup error clusters...
Mike...
Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion
"... after all, He's not a tame lion..."
Be thinking ahead and mark your dance card for NI Week 2015 now: TS 6139 - Object Oriented First Steps

How can I see a run time error?

When I run the VI in development mode the VI works just fine. But after I compile and run the VI I get an error that flashes across the screen and then disappears. Arggg! How can I stop the process to see my error?

Steve,
There are a few possible solutions to this.
One, I am writing an article about right now. It involves writing a Loader. This is a simple VI that loads and runs your main program, so that it can remain as a VI. If this is a viable solution for you (your VIs remain as VIs), then it is probably a great solution, as you won't have to worry about why your VI runs differently as an executable than in development.
The second is a lot more involved. You need to troubleshoot this error. First, you should already have in place some good error handling. If you don't, get it. Once you have it, or if you already do, you need to determine about where the error is coming from, and start putting in some troubleshooting. I always like to create a singl
e Global Variable (this to me is the ONLY good use for a global) with all sorts of indicators to act as a runtime probe (since you can't probe a built application.) You just write values to various controls as you need them, when you need them, and this allows you to view those values. Since this is designed primarily to view data in reentrant VIs, you will have to create a viewer for your built application. Simply create a VI that loads when you run your app that displays all of the global values.
Those are the only suggestions I can offer for now. Without knowing the nature of the error, etc, I can't give you any further advice.

How can we tell if a VI is already running before calling Start Asynchronous Call?

The new Start Asynchronous Call node is awesome for spawning multiple instances of reentrant VIs. However, I've stumbled a bit in using it for non-reentrant VIs. The old practice of using the "Run VI" method would allow us to check the Execution.State of the VI before invoking the method to run it. That way if the State was Running or Run Top Level, we could skip the invoke node and just use a property node to open its front panel. WIth the Start Asynchronous Call node, it looks like we have to use a strictly typed static VI reference, and when we open the VI reference, the VI gets reserved and its Execution.State = Running. So, how can I tell if it is not just reserved by the thread but actually executing before making a redundant Start call?
By the way, the redundant Start has interesting behavior. It will actually cause the targeted VI to be executed again after it stops. Even if you hit the Abort button on the target VI, it will immediately execute again and again equal to the number of times the Start Asynchronous Call node was run. There's nothing wrong with that, and I suppose the simple answer is to just go back to using the old "Run VI" method. It's just that the ability to wire up those inputs directly to the connector pane is so nice. Perhaps I am missing something obvious. Oh, I am referring to the Call and Forget mode (0x80).
Thanks,
Dan
Solved!
Go to Solution.

Just throwing it out there, I know I'm a year.5 late on this but if it's a psuedo-modal dialog or some other window that you only want a single instance visible at one time, you can check the FP.State property on the strictly typed vi reference. If it's loaded and visible to the user it will be "Standard", if it was closed or not opened prior then the state will be "Closed".
I think the standard behavior of serializing execution on another thread would be great for doing a pre-set number of iterations with a sub vi in a non-blocking sort of way but for sub vi's meant for UI interaction checking FP.State works.
Philip
CLD

Error while running Client Program of Entity Bean (BMP) : javax.naming.Name

Hi,
I have tried an entity bean application. I am able to deploy my entity bean in WebLogic 7.0 server. But when I ran the client program I am getting the following error.
javax.naming.NameNotFoundException : Unable to resolve 'java:comp.env/ejb/AccountBean' Resolved: ' ' unresolved : 'java:comp': remaining name 'java:comp.env/ejb/AccountBean'
My ejb-jar.xml is as follows:
<ejb-jar>
<enterprise-beans>
<entity>
<ejb-name>AccountBean</ejb-name>
<home>AccountHome</home>
<remote>Account</remote>
<ejb-class>AccountBean<ejb-class>
<persistance-type>Bean</persistance-type>
<prim-key-class>AccountPK</prim-key-class>
<reentrant>False</reentrant>
<primkey-field>AccountID</primkey-field>
<env-entry>
<env-entry-name>jdbc.drivers</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>oracle.jdbc.driver.OracleDriver</env-entry-value>
     </env-entry>
<env-entry>
<env-entry-name>JDBC-URL</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>jdbc:oracle:thin:@erp:1521:Oracle9i</env-entry-value>
     </env-entry>
     <ejb-ref>
               <ejb-ref-name>ejb/AccountBean</ejb-ref-name>
               <ejb-ref-type>Entity</ejb-ref-type>
               <home>AccountHome</home>
               <remote>Account</Account>
               <ejb-link>AccountBean</ejb-link>
          <ejb-ref>
          <resource-ref>
               <resource-ref-name>jdbc/bmp-account</resource-ref-name>
               <resouce-ref-type>javax.sql.DataSource</resource-ref-type>
               <res-auth>Container</res-auth>
               <res-sharing-scope>sharable</res-sharing-sope>
          <resource-ref>
     </entity>
</enterprise-beans>
<assembly-descriptor>
</assembly-descriptor>
<ejb-jar>
My weblogic-ejb-jar.xml is as follows:
<weblogic-ejb-jar>
     <weblogic-enterprise-bean>
          <ejb-name>AccountBean</ejb-name>
          <entity-descriptor>
               <pool>
               </pool>
               <entity-cache>
                    <cache-between-transaction>false</cache-between-transcation>
               </entity-cache>
               <persistance>
               </persistance>
               <entity-clustering>
               </entity-clustering>
          </entity-descripto>
          <transaction-descriptor>
          </transaction-descriptor>
          <reference-descriptor>
               <resource-descriptor>
                    <res-ref-name>jdbc/bmp-accoun</res-ref-name>
                    <jndi-name>MariJNDI</jndi-name>
               </resource-descriptor>
               <ejb-reference-descriptor>
                    <ejb-ref-name>ejb/AccountBean</ejb-ref-name>
                    <jndi-name>AccountBean</jndi-name>
               </ejb-reference-descriptor>
          </reference-descriptor>
          </weblogic-enterprise-bean>
     </weblogic-ejb-jar>
My Client Program is as follows:
import javax.ejb.*;
public class Client{
public static void main(String[] args){
Account account = null;
     try{
     Context = new InitialContext(System.getProperties());
     AccountHome home = (AccountHome) ctx.lookup("java:comp/env/ejb/AccountBean");
     home.create("123-456-7890","John");
     }catch(...){
Any help is appreciated.
Thanks in advance.
Regards,
Mari.

Hi,
My Client Program is as follows:
import javax.ejb.*;
public class Client{
public static void main(String[] args){
Account account = null;
     try{
Context = new
Context = new
InitialContext(System.getProperties());
AccountHome home = (AccountHome)
AccountHome)
ctx.lookup("java:comp/env/ejb/AccountBean");
     home.create("123-456-7890","John");
     }catch(...){
}What are the System Properties? Are you running the client remotely? Are you running the client as a stand alone Java app or using the Weblogic's Client Runner? 'java:comp' as the jndi name is usually used when the client runs inside the container... But it doesn't seem to be the case.
Kexkey

How to allow cleanup actions to be taken by a reentrant clone before it is killed, when viewed via web server, because of a browser close?

Here is a question I'm having to luck with. I have a VI, set to be reentrant, which is published via the web server. The main VI instance is never interacted with: it makes a clone every time someone navigates to the proper URL, and the user interacts with the newly created clone (never the main instance). A clones is capable of configuring and calling instrument VI's when proper login credentials are entered, which results in browser popups that are controllable on the user's end (though only one user is ever doing this at a time. To clarify, multiple clones can be open simultaneously for login purposes, but only one user is ever interacting with the instruments, which aren't themselves reentrant).
If the user clicks my custom logout button in their browser, it is trivial to close these other, independent instruments and clean up properly. But if the user simply clicks the red X in their browser, there is no graceful shutdown and the instruments which the clone called stay open on the server, when they should be closing.
My experience so far:
No panel close? event seems to be triggered in the clone. The clone simply ceases to be.
The remote_panel_connections property doesn't seem to work correctly in this instance (I haven't had any luck so far), since it is possible for more than one clone to be active, and the main parent that is spawning the clones stays running but isn't interacted with in any way.
What I Need:
A way for the clone VI to recognize that the user has closed their browser, and communicate that it is closing to all active VI's before terminating.
I would like to avoid forcing the instruments that the clone calls to poll constantly to see if the clone VI is present on the network. If there is no other solution but this, I would appreciate a suggestion as to the least resource and code intensive way to implement this type of polling, as the instruments are really meant to be totally independent entities after they are called, rather than sub vi's.
Thanks for any input, let me know if more information is needed.
Solved!
Go to Solution.

Hey MTdev,
Panel close? events cannot be triggered on a VI being viewed or controlled remotely. Some more information on that can be found in the help here:http://zone.ni.com/reference/en-XX/help/371361E-01/lvprop/vi_panel_closeq/. My suggestion would be to set the Title Bar on the front panel of your remote VI to not be visible so that their only option for closing the window is to click the logout button. Are you using Remote Front Panels(http://zone.ni.com/devzone/cda/tut/p/id/3277) to do this instrument control? Using remote front panels allows you to manage a lot of the multiple people accesssing at the same-time type issues so it may be something to look into if you are not already using this method.
Regards,
Kevin
Product Support Engineer
National Instruments

Problems with access to serial port using reentrant code

Hi,
I have a VI that send commands and receive answers from an instrument using
de serial port.
This VI runs perfectly when used alone.
However I'm trying run two instances of that VI simultaneously using
reentrant code and I'm facing some problems.
Sometimes everything is OK but sometimes, in the process of writing to
serial port the following error happen:
Error code 36.
Invalid refnum device.
What is this?
Does someone know how to prevent this?
Thanks in advance for any help.

"Paro, Paula [CMPS:2721:EXCH]" wrote:
>
> Hi,
>
> I have a VI that send commands and receive answers from an instrument using
> de serial port.
> This VI runs perfectly when used alone.
> However I'm trying run two instances of that VI simultaneously using
> reentrant code and I'm facing some problems.
> Sometimes everything is OK but sometimes, in the process of writing to
> serial port the following error happen:
> Error code 36.
> Invalid refnum device.
>
> What is this?
> Does someone know how to prevent this?
>
> Thanks in advance for any help.
You can't use reentrant vi's vith serial vi calls without supervising of
driver.
Use VISA instead and you have to control the VISA session opening and
closing. Another word is that the only one serial port sess
ion should be
opened at a time.
Reentrant vi's for serial port without checking serial port session is a
mistake of program algorithm. Change it in any convenient way.
Sergey Krasnishov
Automated Control Systems
National Instruments Alliance Member
Moscow, Russia
[email protected]
http://acs.levsha.ru

Running Reentrant vi on rt

Similar Messages

Maybe you are looking for