I'm writing a program to control two similar devices in Labview. In order to avoid copying the code I use subVIs. But I have a piece of code where I update some values on the GUI inside a while loop. I'd like to know if it is possible to somehow have this loop inside my subVI and have the subVI sending one of the output parameters after each iteration.
To update your GUI from within a subVI you can do one of the following:
Create a queue or notifier in your top level VI and pass the reference in to your subVI. In the subVI, send the data to the queue or notifier. In the top level VI, have a loop that waits for data on the queue or notifier and writes that to the front panel indicator.
Create a control reference to the front panel indicator in the top level VI and pass the reference to your subVI. In the subVI, use a property node to write the Value property of the indicator.
If you look at the LabVIEW help for the terms in bold you'll find documentation and examples for how to use them.
Of these options, I would use a queue for any data where it's important that the top level VI receives every data point (e.g. if the data is being plotted on a chart or logged to a file) or a notifier where it's only necessary that the user sees the latest value. Using control references for this purpose is a bit 'quick and dirty' and can cause performance issues.
If you need to update more than a couple of indicators like this, you'll probably want to build a cluster containing the data you send to the queue/notifier, or containing the control references. Save your cluster as a typedef so that you can modify its contents without breaking your code.
Another option is a channel wire. A channel wire will send data from a producer loop to a consumer loop without the overhead of a reference & property node and without having to create and close a queue or notifier reference. If you make a simple vi with writer and reader loops as shown in the LabView Help, then select the writer loop and go to Edit -> Create SubVI, you'll have a template to use.
Related
Consider for example this modified Simple TCP sample program:
How can I display the current state of the program like
Wait for Connection
Connected
Connection terminated
on the frontpanel, depending on where the "data flow" currently is.
The easiest way to do this is to place a string indicator on your front panel and write messages to a local variable of this indicator at each point where you want to see a status update.
You need to keep in mind how LabVIEW dataflow works: code will execute as soon as the data it depends on becomes available. Sometimes you can use existing structures to enforce this - for example, if you put a string constant inside your loop and wire it to a local variable terminal outside the loop, the write will only happen after the loop exits. Sometimes you may need to enforce that dataflow artificially, for example by placing your operation inside a sequence frame and connecting a wire to the border of the sequence: then what's inside the sequence will only happen after data arrives on that wire. (This is about the only thing you should use a sequence for!)
This method is not guaranteed to be deterministic, but it's usually good enough for giving a simple status indication to the user.
A better version of the above would be to send the status messages on a queue or notifier which you read, and update the status indicator, in a separate loop. The queue and notifier write functions have error terminals which can help you to enforce sequence. A notifier is like the local variable in that you will only see the most recent update; a queue keeps all the data you write to it in the right order so would be more suitable if you want to log all the updates to a scrolling list or log file. With this solution you could add more features: for example the read loop could add a timestamp in front of each message so you could see how recent it was.
A really good solution to this general problem is to use a design pattern based on a state machine. Now your program flow is clearly organised into different states and it's very easy to add in functionality like sending a different message from each state. There are good examples and project templates for these design patterns included with recent versions of LabVIEW.
You should be able to find more information on any of the terms in bold in the LabVIEW help or on the NI website.
I have set up a multithreading routine in Access which opens up several Access files at the same time and executes a specific function in each file. The files act in parallel. I would like to send Debug.Print messages to the main file which initiates the multithreading.
I'm not sure if it can do this or if there is a better solution.
You have a number of processes, each working on their own part of the bigger picture.
The immediate pane of the "main" IDE belongs to that instance, in that process; you could Alt+Tab and then Alt+F11 to bring up a VBE instance in any/every instance to view that instance's Debug.Print output.
What you want is something like an ILogger implementation that writes the log entries in a dedicated database table: a DatabaseLogger, for example.
You replace Debug.Print with Logger.Log calls; that way you let the database server deal with the multiple incoming threads, and depending on the RDBMS you could even setup a job to cleanup, aggregate and/or archive the older log records. Or whatever, as long as it's not logic I need to care about in VBA code.
Writing to another VBE's immediate toolwindow involves low-level, cross-process Win32 wizardry that doesn't need to clutter up an otherwise nice & tidy VBA project. I wouldn't bother with that, there are simpler solutions.
You could create a PublicNotCreatable UserForm (not an Access Form) in the main application, and pass a reference to it, to all of the parallel apps. Add a custom method to the UserForm, like 'PrintLine(message as string), and each app can callform.PrintLine("app is running")`?
You could then have the UserForm display the output, or possibly, have the UserForm output the message to the Immediate window of the main application.
I'm planning on developing a Monopoly game using a Console application in VB.NET, but with a separate GUI (probably a Forms application) that displays the state of the Monopoly board based on the information in the Console application, so that it can be ignored or used as the players wish. I've been looking into ways of sending information between two programs, and came across Pipes, except they seem complex and I'd like to use a different method if I can avoid it. The following is the methodology I'm currently considering to send information - I'd like to know if there is any way I could improve this methodology, or if you think it's completely stupid and I should just use Pipes instead -
Program 1 is the Console application which controls everything: the state of the game depends on the Console. Program 2 is the GUI/Forms application which follows instructions sent by Program 1 and displays the board accordingly. Program 1 and Program 2 communicate using two text files, Command.txt and CommandAvailable.txt. When something changes on Program 1 - e.g. a player makes a move - a command string is made and added to a queue. Program 1 continually checks CommandAvailable.txt to ensure that the file is empty, and if so, it clears Command.txt and then appends every command string in the queue to Command.txt. When it has finished, arbitrary text is added to CommandAvailable.txt, e.g. "CommandAvailable".
Program 2 continually checks CommandAvailable.txt until it is not empty, meaning that Program 1 has added at least one command to Command.txt. Program 2 then reads every instruction on Command.txt and adds it onto a queue on the other side. CommandAvaiable.txt is then cleared, which will permit Program 1 to add more Commands to Command.txt (because it only adds commands when CommandAvailable.txt is empty and hasn't already been marked by itself.) A separate thread on Program 2 empties the queue of command strings, parses them and executes them.
For example, in the Console, Player 1 may move to Trafalgar Square (or whatever the square would be called.) Program 1/Console would add the Command "move player1 trafalgar_square" to the queue, then check CommandAvailable.txt, and if it is empty, add all the commands in the queue to Command.txt. Program 2/The GUI would check CommandAvailable.txt and as it had been marked by Program 1, read the command, add it to the queue, and then move a picturebox that represents Player 1 to a square.
Please let me know if you think this methodology could be improved, or if you think it's simply stupid and there are far better alternatives or that I should just use Pipes instead. I'm going to be using VB.NET.
I'm having a problem with making my VB.NET application point to something rather than "Application" in Event Log...
I create my custom event log using the function: EventLog.CreateEventSource("My_Source_Name", "My_Log_Name")
where the first parm is the Source Name, and the second parm is the log name. This method works every time it creates the event log's source, but when I'm about to add a new entry, I'm surprised that for some sources the process write the log under my custom log, but for other sources, the log is written in Application!!! (Some times with an error at it's header)!!!!!
I need to know, what exactly is going on?? am I (somehow) following the right way?? if Yes, what are the enhancements that I need to add to my code to make it look much better?? how can I stop this from occurring again so I can have all my logs under my customized log name?? and if No, what is the right way of doing this?? and is there any other way of writing this code (even if the new code was for another solution rather than the event log)??
Thank you very much :)
"To create an event source in Windows Vista and later or Windows Server 2003, you must have administrative privileges."
http://msdn.microsoft.com/en-us/library/5zbwd3s3.aspx
On the other hand, you should have a class (or interface) in charge of logging as a vertical layer on your application. That class is the one in charge of internally write to the appropriate event source.
However, if you need something powerful I really recommend Log4Net.
http://logging.apache.org/log4net/
I have a fairly straightforward SSIS package with a number of Data Flow tasks each with data-flows for multiple tables like shown below:
I want to be able to execute each of these data-flows based on some user-defined variable values that I manipulate using a Script Task in control-flow. Something like, if a variable (say BESTELLDRUCK) value is true, then I want to execute the data-flow for this table (source-conversion-destination tasks), else I want to skip this table and proceed to another table (e.g. AKT_FEHLER) in same data-flow task.
How can I do this? Thanks in advance.
You cannot disable or enable transformations within the Data Flow Task. However, you can enable or disable Data Flow Tasks on the Control Flow tab.
Here is one possible way to do this on Control Flow tab:
If it is possible, move the source --> destination transformations to individual data flow tasks. Something like as shown below.
Let's assume you have created variables for each flow to enable or disable the Data Flow Task based on some condition. For this example, I have hard coded some values.
To dynamically enable or disable Data Flow Tasks based on variable. Click on a Data Flow Task and press F4 to view Properties. On the Properties, click the Ellipsis button next to the Expressions property. You will see the Property Expression Editor.
Select the Property Disable and use the Ellipsis button to enter the expression !#[User::Enable_BESTELLDRUCK] Notice the exclamation sign because the variable is declared to Enable but only Disable property is available to you need to do the opposite.
Repeat the process for other Data Flow Tasks with appropriate variables. Run the package and you will notice that the second Data Flow Task did not execute because the variable Enable_AKT_FEHLER was set to the value False.
Hope that helps.
Reference:
To load multiple tables having same schema within ForEach Loop container, take a look at the below SO answer. It transfers data from MS Access to SQL Server. Hopefully, that should give you an idea.
How do I programmatically get the list of MS Access tables within an SSIS package?
I guess there are enough pointers here for Agent 007 to resolve the issue. I would like to add a few general comments.
Enabling/disabling the tasks dynamically is not a good practice. A better way to disable a task is to use an expression within a precedence constraint. One such reference: http://www.sqlis.com/sqlis/post/Disabling-tasks-Through-Expressions.aspx
As suggested convert each STD (Source-Transform-Destination) into its own DFT. Even better use parent-child pattern. This would help in testing future additions of more DFTs.