Simultaneous execution of JREs

Good morning,
I am trying to see under which conditions do I receive the error message "Java was started but returned exit code=1".
Sometimes I receive this error code when trying to execute more than one Java virtual machine. Also this happens when trying to set the Xmx, Xms and MaxPERMsize parameters to a GB-order size.
Can somebody tell me where could I find which conditions are evaluated by the virtual machine in order to launch such error messages? So I could know under which circumstances could my java software be executed over Windows 32 and 64 bits.
Or at least, does somebody know how could I contact the Java personell and ask them directly (by means of money, of course).
Kind regards.

Thanks for the response. I implemented the notifiers and it seems to have partially fixed the problem. Now when I run the VI it updates the amplitude on every iteration of the for loop. The only problem that I have now is that the while loop that houses the "simulate signal" block stops execution immediately after the amplitude has been updated. My goal is to get the signal to continuously run while updating the amplitude in real time so that I can watch the waveform change. Currently it will update the amplitude, then freeze the waveform with the updated amplitude and subsequently wait for a new amplitude to be passed before updating again. I'm assuming this occurs because of the "wait on notification" block that is used to receive the notification from the for loop. Is there any way to either modify these notifiers to allow for a real time passage of data and simultaneous execution of the while loop, or is there some other type of data passing method that would work better to achieve that end? I have attached my updated VI as a VI snippet like you suggested. Thanks for the help!
Attachments:
Amplitude Stepping.png ‏99 KB

Similar Messages

Simultaneous Execution in Java

I am working on a project which involves simultaneous execution for simulation.
A brief description about the project:
==============================
Consider a network with 'n' nodes in it. In this network each node sends data to the other nodes that it can reach. Assume that nodes in this network can send to data to nodes which are distance 'd' from it.
Now, if node 1 has two nodes node2 and node3 in its reach, it sends its data to those nodes. Not node 2 and node3 start sending data to those nodes that it can reach.
(Note: Node2 and Node3 has to send data simultaneously to the nodes that they can reach)
You can visulize this execution as a tree.
I have never worked in Java Java Concurrent Programming. Could any one please suggest me any kind of framework that i can use for this problem.

Can you do the following?
      1       (Time 0)
   2      3   (Time 1)
4   5 6   7 (Time 2)At Time 0, you process 1-2 and 1-3, sequentially. Then, the time becomes Time 1.
At Time 1, you process 2-4, 2-5, 3-6, and 3-7, sequentially. Then, the time becomes Time 2.
And continue the process as needed.

How prevent simultaneous execution of multiple button threads?

My AS 3 program has multiple buttons. Users can select one and then immediately select another and this causes 2 threads that collide. Once one button is executing, I want the other buttons to ignore clicks.
I've tried using a lock:Boolean to indicate a button is being processed. Each button checks lock. My logic is such that when the AS 3 processor detects a locked condition, it abandons execution of that button. However, surprisingly, it abandons execution only termporarily ... once the the boolean is unlocked, AS 3 comes back and executes the button.
The problems are twofold: 1) the first time the 2nd button attempts to execute (by checking lock), when it returns (from checking lock) and attempts to pick up processing where it left off, it seems to forget where it was and does not utlimately complete its task(s); possibly variables have been altered, it is difficult to say. That is, AS 3 is unable to successfully pickup where it left off on the first button.
2) the second problem is that AS 3 incorrectly returns to button 2 after the lock condition is cleared. It persists and will execute that button.
Can anyone tell me how once one button is selected, the others can be locked out and won't execute?? Multiple threads from these buttons is a problem.
Thanks in advance.
Steve @ U Iowa

dmennenoh - OK. The downside to that type of solution is that each button has to "know" which other buttons are on the stage at that time, but, yes, that should work. Do you think turning their visibility off would or would not be as effective as removing the event listeners? I'm thinking turning visiblity on or off is simpler and simpler to manage. Thanks for your help.

How to restrict simultaneous execution of two programs?

Hi Experts,
Need inputs for the situation described below:
We have two programs prog A and prog B. These are independent executable programs and have no dependency on each other. I want to restrict execution of prog B if prog A is running in any session by any user. Is there any system/basis table which stores runtime status of all the programs? There should be some table where all the currently executing programs get stored and once program is completed, entry is cleared from the table.
One way can be:
When prog A has started execution, add an entry in any Z table and at the time of finishing delete the particular entry. In prog B check that the table has any entry for prog A. If yes that means prog A is still running.
Issue with this approach is, if program A has some error or cancelled while execution, it will not delete its own entry and hence even if prog A is finished, prog B will find entry in Ztable.
Any other way to achieve this functionality?
This is very urgent.Please help!
TIA
Abhishek

Hi,
Although I don't understand why you need to serialized two programs
that have no dependency on each other, maybe the following code can help provided the programs are executed using specific tcodes.
DATA: BEGIN OF USR_TABL OCCURS 10.
INCLUDE STRUCTURE UINFO.
DATA: END OF USR_TABL.
CONSTANTS: OPCODE_LIST LIKE TH_OPCODE VALUE 2.
refresh USR_TABL.
CALL 'ThUsrInfo' ID 'OPCODE' field OPCODE_LIST
ID 'TAB' FIELD USR_TABL-SYS.
sort usr_tabl by mandt bname.
You can check wheter the other program(tcode) is being run from itab USR_TABL, good luck.
Jeffrey Satriadi

Newbie Question -- Simultaneous Execution for Labview/DAQ

Hey, I am an undergrad student who is fairly new to labview and control systems and I am working on a senior project. I am wanting to use labview to simultaneously control two separate machines. Both machines would send back data to be saved to a file. They would both be connected to a NI DAQ(SC-2345). Is this reasonably attainable? Will labview and/or the DAQ have problems running two machines simultaneously? I would love any suggestions. Thanks

Let me see if I have your setup pictured correctly. You have 1 PC, 1 DAQ card that is connected to the SC-2345 signal conditioning carrier. Do those modules, you have two different physical machines you want to control. Am I correct?
Do you want to have one LabVIEW application controlling both machines independently? Or two different LabVIEW applications each controlling one machine?
Your one constraint is that since there is only one DAQ card, all DAQ functions have to be handled at a single point of code otherwise you'll get errors about resource conflicts. In other words, you can't have two separate programs eaching trying to work with a single DAQ card.
So you can have a single point of interface with the DAQ card and use architectures such as Producer/Consumer to pass messages back and forth from your other parts of the code. The other parts of the code can be two independent loops that handle the machine control logic for each machine.
The easiest to program would be to have on application that handles both machines. It would have 3 loops, two loops where each loop is for logic for each machine, and one loop that handles the DAQ communication.
If you want to have two separate applications, you can do that as well where each application handles the machine logic and a third background application handles the DAQ communication. It just needs a little bit more sophisticated communication scheme to pass data between the different applications.

Simultaneous Execution with image capture

Hi I'm writing a program that I want to simultaneously run two loops.
One moves an actuator a given amount then saves the current image,
we'll call it the actuator loop. The other loop would provide a live
view of our images from our camera.
The problem is that I need the live preview image to run before the
other loop so I can change exposure, etc. I also need it to run after I
start the moving actuator loop. While both are running I will need to
be able to send the images from the live view loop to the moving
actuator loop. Is this possible and what kind of design pattern would
you recommend?
I can explain more if this made no sense.
Thanks,
-Shane

Hi Shane,
The LabVIEW Application Design Patterns presentation would be a good place to start, but with the information you have given it seems pretty clear you're looking for a Producer/Consumer architecture. In LabVIEW, there is a VI template for Producer/Consumer, so most of the work is done for you.
Producer/Consumer allows you to pass information between loops using queues without losing any data. In this case, the data queued is going to be an image from a camera.
Let me know if you have any further questions/comments/concerns. Cheers.
| Michael K | Project Manager | LabVIEW R&D | National Instruments |

Simultaneous Execution of Events

Hi. I've constructed a VI using event structure. The problem I have is when I'm pressing a button, I cannot press other buttons to work simultaneously(For example, when I press "w" to throttle, I can't press "d" to yaw). Is there any way I can change that? Please advice.
Attachments:
Buttonssss_latest.vi ‏30 KB

Did you try Uncheck lock front panel untill event finishes while creating event??
Thanks
uday,
Please Mark the solution as accepted if your problem is solved and help author by clicking on kudoes
Certified LabVIEW Associate Developer (CLAD) Using LV13
Attachments:
Buttonssss_latest (1).vi ‏29 KB

Simultaneous execution of time critical parts(one is the drive connected to serial port and the other is the DAQ) in a vi

We are developing a software for a cyclic spin test using Drive.
The drive software consists of a profiler part which should be running in a 50ms
interval.(every 50msec th operation should happen).
This Part uses a DAQ card.
To get some digital status we use serial link .
The status update can be every 250msec.
The problem is that the status read takes a minimum of 70msec to complete
(The serial protocol for the drive specifies some delay b/w operation).
We would like to have the status without affecting the 50msec operation.
How can we do this?
We run Labview 6.0 on Windows2000.

I`m not sure how the serial VIs affect the mutithreading of the LabVIEW environment, but setting LabVIEW to run multithreaded and running the two operations independent of each other (in two while loops without data-dependency between them) might do it. You will find the option for multithreading under "options". Bear in mind that a re-start of LabVIEW is necessary before the changes come into effect.
I would time-stamp the reply of the drive with the time of the request, not after receiving the data.
Hope this helps
Shane
Using LV 6.1 and 8.2.1 on W2k (SP4) and WXP (SP2)

Implementing simultaneous execution of same activity instances

We need to run instances of a particular activity/child process, in parallel. The number of instances has to be dynamic (based on a query from database or the like)

If you do the file-write operations in a child process, there is a way to configure a child process (from the parent) to run asynchronously.
You could put the child process in a for-each loop, iterate over the rows from your query, and basically launch the child process to write. The loop would repeat for the next row without waiting for the chile process write operations to complete.
The drawback to this is that, if you have something downstream in the workflow that needs to start running after *all* parallel operations are complete, you have to do some other stuff to indicate "start all operations" and "all operations complete". However, it's an easy way to have these child processes running in parallel, and having a dynamic number of them at a time.

Is this roughly how the labVIEW Execution Systems work?

I've not taken a class in OS design, so I don't know the strategies used to implement multitasking, preemptive or cooperative. The description below is a rough guess.
LabVIEW compiles Vis to execute within its own multitasking execution environment. This execution environment is composed of 6 execution systems. Each execution system has 5 priority queues (say priorities 0->4). Vis are compiled to one or more tasks which are posted for execution in these queues.
An execution system may either have multiple threads assigned to execute tasks from each priority queue, or may have a single thread executing all tasks from all priority queues. The thread priorities associated with a multithreaded execution system are assigned according to the queue that they service. There are therefore 5 available thread priority levels, one for each of the 5 priority level queues.
In addition to the execution queues, there are additional queues that are associated with tasks suspended in various wait states. (I don't know whether there are also threads associated with these queues. It seems there is.)
According to app. note 114, the default execution environment provides 1 execution system with 1 thread having a priority level of 1, and 5 execution systems with 10 prioritized threads, 2 threads per priority queue. NI has titled the single threaded execution system "user interface" and also given names to the other 5. Here they will be called either "user interface" or "other".
The "user interface" system is responsible for all GUI actions. It monitors the keyboard and mouse, as well as drawing the controls. It is also used to execute non-thread-safe tasks; tasks whose shared objects are not thread mutex protected.
Vis are composed of a front panel and diagram. The front panel provides an interface between the vi diagram, the user, and the calling vi. The diagram provides programmatic data flow between various nodes and is compiled into one or more machine coded tasks. In addition to it own tasks, a diagram may also call other vis. A vi that calls another vi does not actually programmatically branch to that vi. Rather, in most cases the call to another vi posts the tasks associated with the subvi to the back of one of the labVIEW execution system�s queues.
If a vi is non-reentrant, its tasks cannot run simultaneously on multiple threads. This implies a mutex like construction around the vi call to insure only one execution system is executing the vi. It doesn�t really matter where or how this happens, but somehow labVIEW has to protect an asynchronous vi from simultaneous execution, somehow that has to be performed without blocking an execution queue, and somehow a mutex suspended vi has to be returned to the execution queue when the mutex is freed. I assume this to be a strictly labVIEW mutex and does not involve the OS. If a vi is reentrant, it can be posted/ran multiple times simultaneously. If a vi is a subroutine, its task (I think there is always only one) will be posted to the front of the caller's queue rather than at the back of the queue (It actually probably never gets posted but is simply mutex tested at the call.) A reentrant-subroutine vi may be directly linked to its caller since it has no restrictions. (Whether in fact labVIEW does this, I don�t know. In any event, it would seem in general vis that can be identified as reentrant should be specified as such to avoid the overhead of mutexing. This would include vis that wrap reentrant dll calls.)
The execution queue to which a vi's tasks are posted depends upon the vi execution settings and the caller's execution priority. If the caller's execution priority is less than or equal the callee's execution settings, then the callee's tasks are posted to the back of the callee's specified execution queue. If the caller's execution priority is greater than the callee's specifications, then the callee's tasks are posted to the back of the caller's queue. Under most conditions, the vi execution setting is set to "same as caller" in which case the callee�s tasks are always posted to the back of the caller's execution queue. This applies to cases where two vis are set to run either in the other execution systems or two vis are set to run in the user interface execution system. (It�s not clear what happens when one vi is in the �user interface� system and the other is not. If the rule is followed by thread priority, any background tasks in the �other� systems will be moved to the user interface system. Normal task in the �other� systems called by a vi in the �user interface� system will execute in their own systems and vice versa. And �user interface� vis will execute in the caller�s �other� system if the caller has a priority greater than normal.)
Additionally, certain nodes must execute in the "user interface" execution system because their operations are not thread-safe. While the above generally specifies where a task will begin and end execution, a non-thread safe node can move a task to the �user interface� system. The task will continue to execute there until some unspecified event moves it back to its original execution system. Note, other task associated to the vi will be unaffected and will continue to execute in the original system.
Normally, tasks associated with a diagram run in one of the �other� execution systems. The tasks associated with drawing the front panel and monitoring user input always execute in the user interface execution system. Changes made by a diagram to it own front panel are buffered (the diagram has its own copy of the data, the front panel has its own copy of the data, and there seems to be some kind of exchange buffer that is mutexed), and the front panel update is posted as a task to the user interface execution system. Front panel objects also have the advanced option of being updated sequentially; presumably this means the diagram task that modifies the front panel will be moved to the user interface execution system as well. What this does to the data exchanged configuration between the front panel and diagram is unclear as presumably both the front panel and diagram are executing in the same thread and the mutex and buffer would seem to be redundant. While the above is true for a control value it is not clear whether this is also true for the control properties. Since a referenced property node can only occur on the local diagram, it is not clear it forces the local diagram to execute in the user interface system or whether they too are buffered and mutexed with the front panel.
If I were to hazard a guess, I would say that only the control values are buffered and mutexed. The control properties belong exclusively to the front panel and any changes made to them require execution in the �user interface� system. If diagram merely reads them, it probably doesn�t suffer a context switch.
Other vis can also modify the data structure defining the control appearance and values remotely using un-reference property nodes. These nodes are required to run in the user interface system because the operation is not thread-safe and apparently the diagram-front-panel mutex is specifically between the user interface execution system and the local diagram thread. Relative to the local diagram, remote changes by other vis would appear to be user entries.
It is not clear how front panels work with reentrant vis. Apparently every instance gets its own copy of the front panel values. If all front panel data structures were unique to an instance, and if I could get a vi reference to an instance of a reentrant vi, I could open multiple front panels, each displaying its own unique data. It might be handy, sort of like opening multiple Word documents, but I don�t think that it�s available.
A note: It is said that the front panel data is not loaded unless the front panel is opened. Obviously the attributes required to draw an object are not required, nor the buffer that interfaces with the user. This rule doesn�t apply though that if property references are made to front panel objects, and/or local variables are used. In those cases at least part of the front panel data has to be present. Furthermore, since all data is available via a control reference, if used, the control�s entire data structure must be present.
I use the vi server but haven�t really explored it yet, nor vi reference nodes, but obviously they too make modifications to unique data structures and hence are not thread-safe. And in general, any node that accesses a shared object is required to run in the user interface thread to protect the data associated with the object. LabVIEW, does not generally create OS level thread mutexes to protect objects probably because it becomes to cumbersome... Only a guess...
Considering the extra overhead of dealing with preemptive threading, I�m wondering if my well-tuned single threaded application in LV4.1 won�t out perform my well-tuned multithreaded application in LV6.0, given a single processor environment�
Please modify those parts that require it.
Thanks�
Kind Regards,
Eric

Ben,
There are two types of memory which would be of concern. There is temporary and persistent. Generally, if a reentrant vi has persistent memory requirements, then it is being used specifically to retain those values at every instance. More generally, reentrant code requires no persistent memory. It is passed all the information it needs to perform its function, and nothing is retained. For this type of reentrant vi, memory concern to which you refer could become important if the vis are using several MBytes of temporary storage for intermediate results. In that case, as you could have several copies executing at once, your temporary storage requirements have multiplied by the number of simultaneous copies executing. Your max memory use is going to rise, and as labview allocates memory rather independently and freely, the memory use of making them reentrant might be a bit of a surprise.
On the other hand, the whole idea of preemtive threading is to give those tasks which require execution in a timely fashion the ability to do so regardless of what other tasks might be doing. We are, after all, suffering the computational overhead of multithreading to accomplish this. If memory requirements are going to defeat the original objective, then we really are traversing a circle.
Anyway, as Greg has advised, threads are supposed to be used judiciously. It isn't as though your going to have all 51 threads up at the same time. In general I think, overall coding stategy should be to minimize the number of threads while protecting those tasks that absolutely require timely execution.
In that sense, it would have been nice if NI had retained two single threaded systems, one for the GUI and one for the GUI interface diagrams. I've noticed that control drawing is somewhat slower under LV6.0 than LV4.1. I cannot, for example, make a spreadsheet scroll smoothly anymore, even using buffered graphics. This makes me wonder how many of my open front panel diagrams are actually running on the GUI thread.
And, I wonder if threads go to sleep when not in use, for example, on a wait, or wait multiple node. My high priority thread doesn't do a lot of work, but the work that it does is critical. I don't know what it's doing the rest of the time. From some of Greg's comments, my impression is it in some kind of idle mode: waking up and sleeping, waking up and sleeping,..., waking up, doing something and sleeping... etc. I suppose I should try to test this.
Anyway that's all an aside...
With regard to memory, your right, there are no free lunches... Thanks for reminding me. If I try this, I might be dismayed by the additional memory use, but I won't be shocked.
Kind Regards,
Eric

How to create a PR with a group of line items in Maintenance Order

Hi,
I reqest for a solution for this scenario.
I created aMaintenance Order with 45 materials assigned in that.
Now I would like to have the ability to group split all line items in to certain groups and individual PRs for these groups
I would like to group these 45 items in 10 or 12 groups and create PR for each of these groups.
Plz guide how can I do this with any devlopment of a report.

lukko wrote:
Thank you for the reply. My first guess was that in case of arrays everything inside the VI should be closed in a loop and perhaps with varying number of inputs the loop could be avoided and this would improve simultaneous execution for multi-core CPUs.
I would not base all conclusions on first guesses.
Working with arrays is typically significantly more efficient (e.g. SIMD). We also have the parallel FOR loop where several iterations can be executed in parallel, thus fully supporting simultaneous execution.
How exactly are you expecting the code to look like if you have a variable number of connectors?
LabVIEW Champion . Do more with less code and in less time .

How do you disable "Run with Multiple Threads" in a standalone EXE

I have a program written in Labview 6.1. After moving to a different hardware platform, my program has started crashing at the same point every time it is run. I eventually found out that the cause of the crash is the fact that the new hardware has a dual core processor. I confirmed this by disabling "Run with multiple threads" and now the program works fine. What I need to know now is how to disable the same setting in a built EXE file, since as far as I know the "Run with multple threads" setting only affects execution in the Labview Dev environment.
Thanks for any help,
Dave

Greg McKaskle once posted that using a non-reentrant (VI is NOT re-entrant) wrapper VI to make the calls to the dll will prevent simultaneous execution of the dll.
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

Passing Dataset in Subreport

Hi,
I have a report that has a summary section (main report) and details section (subreport located in the report footer of the main). Both the main and subreport pull data from the same tsql stored procedure. Is there a way i can pass the dataset from the main report to the subreport so that i dont have to make 2 calls to the stored procedure as it is very expensive? Can this be done through shared variables?
Thanks in advance,
Will

I suppose it might be feasible using shared array variables, but arrays have a limit of 1000 elements.
Can the summary section be built with a crosstab? That would allow you to use one call to the SP to generate both sets of results.
Lastly, you could store the results of the SP call into a table in the database, using some identifier to distinguish separate report runs (for simultaneous executions), so the SP is only called once (all within an SQL Command in the report), then write both parts of the report over the results table. You'd want to clear the results table periodically, so you may also want a run timestamp in the table.
Other than the above, I don't think there's another way to reduce the SP call to one.
HTH,
Carl

User-specified DAQ interruptions, instrument control through serial communication

I'm working on an instrument control program, and I've run into a structural problem that I cannot figure out.
The instrument in question is effectively a thermostat.
The program has two functions:
1.) Background sampling to record temperature in a log over time.
2.) Adjust temperature according to user input
The issue is that the instrument uses EIA-232 serial communication to talk to the PC.
This prohibits simultaneous execution. Attempting to send a command while the program is taking a sample will result in serial blockage errors.
So the program must interrupt background sampling until the specified command has been completed.
I can't figure out how to do this.
My best idea was to create a manual pause control. If the user wants to adjust the temperature, he hits a switch to pause the sampling, sends the appropriate command, then hits the switch again to reinitiate sampling. This method will suffice, but is not ideal.
Beyond that, I really have no idea how to prevent the two functions from running into each other.
Help structuring this program would be greatly appreciated,
Thank you

Look into Semaphores (icons with traffic light glyphs)
Set up a Semaphore resource to the COM port that is wired to two parallel structures.
One structure would do the background polling, the other would handle setting changes.
Prior to background poll, lock the resource, then unlock it after the poll. Likewise for the setting change command.
When a resource is locked, the other process cannot access it until it is unlocked. Be sure to dispose of the Semaphore when ending the program.
-AK2DM
~~~~~~~~~~~~~~~~~~~~~~~~~~
"It’s the questions that drive us.”
~~~~~~~~~~~~~~~~~~~~~~~~~~
Attachments:
SempahoreExample.jpg ‏256 KB

Handling multiple events in web application

We are converting a window application to a web application. We are facing an issue while implementing the web application with Java on front end and Oracle DB in back end. Consider a field with a car registration number which needs to be verified if it exists in the DB and fetch the remaining values related to the car and display it. At the same time we also need to save the car registration number in the form (displayed in the browser) so that other operations (such as invoicing) can happen on the car. We have a constraint that we cannot touch any of the server procedures in the DB (which handles all DB calls) but could only play with the functions in the UI.
Now the verification of the reg. no. happens whenever we go 'out of focus' from the text box where the reg.no. is written. However, if the user presses 'save' button to save the reg.no., verification should also occur and data should be saved. Now the problem we are facing is that on pressing the save button, two events are occurring simultaneously - 1. textbox with reg.no. is getting 'out of focus' and 2. save button is getting pressed resulting in verifying the reg.no. again. Due to this two events happening simultaneously, one or other method is failing leading to the car reg.no. not getting verified and saved as it should be.
Could anyone think of any solution to overcome the issue?
/Mayank

Hi,
Your assumptions are all correct. Indeed there is Javascript code executing on focus change and AJAX is doing the validations by inturn calling an oracle procedure through some Java rountine. The two requests are overlapping and hence blocking the complete execution of either, leading to the validation not taking place at all.
The webpage gets refreshed everytime an event occurs and thus the next event can take place only after the page has refreshed once (after completing all the validations linked to that event). The problem is occuring since the page is not getting time to refresh. With simultaneous execution of 2 events, the validations related to 'Out of focus' remains incomplete before the 'save function' starts. I am constrained not to put the validation related to 'Out of Focus' in the beginning of 'save' event since that would alter functionality of the 'save' event. Again, I am not allowed to change any of the server procedures on the DB side and have to pass exactly the same i/o parameters for it to function properly.
What I am trying to find is: Whether it is possible to find out (using some global variables) that when the 2 events are happening simultaneously, their functionalities could be combined and serialized in just one refresh of the webpage. and how?
I am trying to get this project done by Java resources and am myself not very technical with Java. If a solution exists and I get to know it exists, I can guide the programmers to try out the approach that come up.
Thanks so much :)

Simultaneous execution of JREs

Similar Messages

Maybe you are looking for