I have a built labview application .exe within which there is a labview queue. I would like to put items into this queue from a labview vi which exists outside of the application.
Is this possible?
It is not possible as, .exe has its own memory pool and it will not share its memory with LabVIEW vi.
Consider using network structures, such as NSP, or Network Streams or TCP/IP.
Related
I have and issue that the only way the FPGA on a myRIO Module runs is if it is programmed over USB. It does not run after powering down and back up. It does run after unplugging the laptop after it has been programmed over USB. I suspect that not running after a power cycle is because the FPGA is only getting the image loaded internally over USB.
Is there some special LabVIEW command to program the serial flash on the FPGA so that the FPGA runs at powerup, or does programming the FPGA over USB always program the serial Flash?
Do you have just FPGA part, and no Real-Time application? In case of just FPGA part, it is enough to build bitfile, and then deploy it (actually, upload it to myRIO and set to run at boot). Here is Knowledgebase article from NI about how to achieve it.
In case when you also have Real-Time part, then it should be also deployed, and set to run at the boot. Here is another detailed article about how to configure it: Deploy a Startup Application to Your MyRIO.
I am running Node-Red on a Raspberry Pi 3. The node-red program allows me to run the Input/Output modules.
I was wondering if I can use LabVIEW to show my results from node red on the front panel of LabVIEW or do I have to create a separate program in LabVIEW to run my I/O modules.
You could try one of the following:
Run your Node-Red program and communicate with the Node-Red program via LabVIEW using the Node-Red API. You would need to rebuild the GUI in LabVIEW
Insert the Node-Red Webpage into LabVIEW
If you're using windows, place an ActiveX container from the
containers palette on the FP, right click and select Insert ActiveX
object. Find the Internet Explorer object (it may be called Microsoft
Web Browser) and use property and invoke nodes to load the URL you
want.
To me either option doesn't really make sense. If you already have LabVIEW, you could just use LabVIEW to talk with your sensors.
I have a Visual C++ Program that needs to use another program to run some specific functions to communicate with my USB device. This second program is provided by the company of by USB Device.
The company also provides the DLL and Library to access the communication module.
The program runs just fine. I can communicate very well with the USB Device.
The problem is that the communication with the USB Device is not the only function of my Visual C++ program, so it should be able to open the program even if the communication module is not installed.
Using the method RegOpenKeyEx, I succeeded to check if the communication module is installed or not. Therefore I can just avoid calling the functions to access the usb device if the communication module is not available.
The problem is that my program is still not opening in a computer without the communication module. I appears the error:
"The Appication was unable to start correctly(0x000007b). Click OK to close the application."
Is it possible to solve my problem?
Instead of statically linking to the DLL, you need to dynamically load it. Then you can choose to load it or not based on whether it's installed. Here is an article showing how to do this, and Here is an SO question with some more detailed info on accessing the contents of a dynamically loaded DLL.
I would like to start a new instance of a wcf service host from another (UI) application. I need the service to be out of process because I want to make use of the entire 1.4GB memory limit for a 32bit .NET process.
The obvious method is to use System.Diagnostics.Process.Start(processStartInfo) but I would like to find out whether it is a good way or not. I am planning on bundling the service host exe with the UI application. When I start the process, I will pass in key parameters for the WCF service (like ports and addresses etc). The UI application (or other applications) will then connect to this new process to interact with the service. Once the service has no activity for a while, it will shut itself down or the UI can explicitly make a call to shut the service down.
You can definitely do this:
create a console app which hosts your ServiceHost
make that console app aware of a bunch of command line parameters (or configure them in the console app's app.config)
launch the console app using Process.Start() from your UI app
That should be fairly easy to do, I'd say.
Perhaps I'm completely offbase here, but I don't think there is a 1.4 GB memory limit for .NET processes. The memory allocated for each process is managed by the OS. For 32-bit opeating systems, there is a 4 GB memory space available, but that is shared among all of the processes. So while it may appear that there is only 1.4 GB available, it's not technically true.
The only reason I bring that up is to say that the other way to approach this would be to load your WCF service inside a separate AppDomain within your UI application. The System.AppDomain class can be thought of as a lightweight process within a process. AppDomains can also be unloaded when you are finished with them. And since WCF can cross AppDomain boundaries as well as process boundaries, it's simply another consideration.
If you are not familiar with AppDomains, the approach that #marc_s recommended is the most straightforward. However, if you are looking for an excuse to learn about AppDomains, this would be a great opportunity to do so.
I'm exploring the possibility of writing an application in Erlang, but it would need to have a portion written in Cocoa (presumably Objective-C). I'd like the front-end and back-end to be able to communicate easily. How can this best be done?
I can think of using C ports and connected processes, but I think I'd like a reverse situation (the front-end starting and connecting to the back-end). There are named pipes (FIFOs), or I could use network communications over a TCP port or a named BSD socket. Does anyone have experience in this area?
One way would be to have the Erlang core of the application be a daemon that the Cocoa front-end communicates with over a Unix-domain socket using some simple protocol you devise.
The use of a Unix-domain socket means that the Erlang daemon could be launched on-demand by launchd and the Cocoa front-end could find the path to the socket to use via an environment variable. That makes the rendezvous between the app and the daemon trivial, and it also makes it straightforward to develop multiple front-ends (or possibly a framework that wraps communication with the daemon).
The Mac OS X launchd system is really cool this way. If you specify that a job should be launched on-demand via a secure Unix-domain socket, launchd will actually create the socket itself with appropriate permissions, and advertise its location via the environment variable named in the job's property list. The job, when started, will actually be passed a file descriptor to the socket by launchd when it does a simple check-in.
Ultimately this means that the entire process of the front-end opening the socket to communicate with the daemon, launchd launching the daemon, and the daemon responding to the communication can be secure, even if the front-end and the daemon run at different privilege levels.
One way is Theo's way with NSTask, NSPipe and NSFileHandle. You can start by looking at the code to CouchDBX http://couchprojects.googlecode.com/svn/trunk/unofficial-binary-releases/CouchDBX/
Ports are possible but not nice at all.
Is there some reason for why this communication can't simply be handled with mochiweb and json communication?
Usually when creating Cocoa applications that front UNIX commands or other headless programs you use an NSTask:
Using the NSTask class, your program can run another program as a subprocess and can monitor that program’s execution. An NSTask object creates a separate executable entity; it differs from NSThread in that it does not share memory space with the process that creates it.
A task operates within an environment defined by the current values for several items: the current directory, standard input, standard output, standard error, and the values of any environment variables. By default, an NSTask object inherits its environment from the process that launches it. If there are any values that should be different for the task, for example, if the current directory should change, you must change the value before you launch the task. A task’s environment cannot be changed while it is running.
You can communicate with the backend process by way of stdin/stdout/stderr. Bascially NSTask is a high-level wrapper around exec (or fork or system, I always forget the difference).
As I understand it you don't want the Erland program to be a background daemon that runs continuously, but if you do, go with #Chris's suggestion.
The NSTask and Unix domain socket approaches are both great suggestions. Something to keep an eye on is an Erlang FFI implementation that's in the works:
http://muvara.org/crs4/erlang/ffi
erl_call should be usable from an NSTask. I use it from a Textmate command and it is very fast. Combining erl_call with an OTP gen_server would let you keep a persistent backend state with relative ease. See my post on erl_call at my blog for more details.
Using NSTask you may also consider using PseudoTTY.app (which allows interactive communication)!
Another sample code of interest could be BigSQL, a PostgreSQL client that enables the user to send SQL to a server and display the result.
open -a Safari http://web.archive.org/web/20080324145441/http://www.bignerdranch.com/applications.shtml