01-27-2010 08:39 AM
I'll give the whole picture here, but I'm not very hopeful because I see other people have had similar problems with no solutions. I am using Labview 2009 and I'm not sure what version of Modbus I have, it was the newest version available in early 2009.
I have a joystick plugged into computer1 (Master) which does not have Labview. Computer1 is connected via Remote Desktop to computer2, which is running the MB Ethernet Example Slave in Labview.
In order to get the joystick info from computer1 to computer2, I built an .exe that takes the joystick info and sends it over modbus. I began getting error 66 randomly while using the MB Ethernet Master Query in the .exe, which would immediately be followed by Error 62 if I tried to send another data point.
So, I replaced the Master Query with just the MB Ethernet transmit in the .exe, since the slave is not writing anything back to the master. Now I only get error 62, and it is still random.
I seem to be able to send a boolean value (from a switch on the joystick) without any trouble. But when I start passing the joystick position, which I have converted to U16, it errors out eventually. Sometimes I can move the joystick continuously for several seconds (30-45), and sometimes it is almost immediate.
Also, when I view computer2 over remote desktop, the error occurrs more frequently. I know the Ethernet switch is working, and I have had this problem before when directly connecting two computers with a twisted cable.
Can somebody please help me with this, or suggest a better way of doing it? I only need to pass one U16 and one or two booleans, so if there is something besides Modbus that I can use, I'm all ears.
01-27-2010 09:22 AM
It's not clear to me why you have computer 1 connect to computer 2 using remote desktop.
You could look at using network shared variables for passing data between the two computers. Using Modbus adds a layer of complication that isn't necessary. Modbus is usually intended for communicating with industrial hardware.
If you posted the VI's that you have running on each computer, it would be easier for others to figure out where you problem may be occurring.
01-28-2010 08:41 AM - edited 01-28-2010 08:43 AM
You are correct, I should be using shared variables. I worked on doing just that for awhile yesterday and acheived nothing but a headache. I am going to start from scratch, no remote desktop, no modbus, just shared variables, that part is all becoming clear. Now, my problem is how to get the executable to communicate to the host running LV.
I think I have read all of the articles on using shared variables with executables, but am still very confused, and here is what I think I need to know. Just as a refresher, I will be interacting with computer1, no Labview, just an .exe. Computer2 has Labview and I think should host the shared variables. Also, computer2 will be different computers at different times:
1. The executable on computer1 needs to contain the application invoke node to deploy the library, but I don't know what the path is to get to the host that will hold the library. I assumed I just listed the IP address and the path on that computer, but that didn't seem to work, maybe because of question2
2. I'm not sure how to host the library on computer2, which again, is running a VI
3. I am confused by the shared variable deployment screen in the application builder. Why would I deploy the library from the .exe which will not be on a computer that is hosting the library. If I don't have it automatically deploy, then how do I deploy it?
I will post the basic project shortly.
01-28-2010 09:01 AM
01-28-2010 10:08 AM - edited 01-28-2010 10:11 AM
I'd recommend taking the VI's out of the library. Just save the Library for the shared variables. I'm not sure if that is the cause of your problem, but it's possible. I don't know how LabVIEW would handle deploying a library that has a VI in it that may already be running.
One problem I see is that you are cross-linking the shared variables. The one variable in one library is bound to the variable in the other library. And vice versa. Don't do that. It creates a battle between the two as each tries to update itself from the other.
Decide which computer you want to be the primary computer. Host the shared variable on it. Don't bind it to anything. On the other computer, host a shared variable that is bound to the shared variable on the first library. Now you've basically created one master variable, and one dependent variable. When you cross-bound them, you basically have two variables each contending to be the master and it just won't work.
One other possibility is that the one variable you have is bound to "\\fog0z4b7hx01\Remote Throttle\Throttle Position", I don't know if the "fog0z" stuff is a legitimate computer name for you or something corrupted.
01-28-2010 11:37 AM
Success! The cross binding was a big part of the problem, I had forgotten I'd done that, and I was actually just guessing, so I'm not sure if the fog.... was correct either.
SO, here is what I did to get this to work, in case anybody else comes across this (and in case I forget).
1. I think I'm hosting the library on the Labview computer (computer2), although, it appears that this done simply by pressing run on the VI that is running on this computer. The variable in this VI is bound to the one created under the library for the .exe VI. I'm a little confused here, because they are actually the same variable, just copied and pasted inside the project explorer window. I'm not sure if I really need the two libraries, or if I even needed to bind them since they are one and the same?
2. The .aliases file: I opened this up in notepad, and all it contains is the IP address of the computer2, which is the one that I am making the .exe on and also the one that is currently running labview and hosting the library. If, in the application builder/Advanced, I leave the check mark on Use the default project aliases file, the .exe does not work. I think it is because it tries to connect to (local host) instead of (169.254.74.250), the IP address of the local host. If, however, I open the .aliases file in notepad and save it under a new name, unchanged, and then uncheck the box and add this file, the .exe works. I think because it now looks for (169.254.74.250). Make sense? If the .exe stayed on the same machine, then local host and 169... would be the same thing, but since the .exe moved across the network, it now needs the IP address.
I'm guessing that when I move this project to a new set of computers, I will have to open the .aliases file in the .exe folder on computer1 and change it to the IP address of computer2. Hopefully I will not have to rebuild the .exe, because computer2 will not have the version of Labview that can build an .exe.
3. I took the invoke node out of the .exe code. There is nothing in the .exe code, or the VI running on the host computer that has anything to do with connectivity other than writing to and reading the shared variables.
4. In application builder/Shared Variable Deployment, I DID NOT check the box that says Deploy shared variable libraries at application execution. I don't understand how this could possibly work unless I was leaving the .exe on this computer.
So in the end, it was pretty simple, just a couple of nuances that needed sorted out. I still think the NI explanations of using shared variables with EXEs are very confusing, and I'm not sure what I will have to do to change the VI on computer1 to an EXE, although that will probably be a requirement on down the road.
Thanks for the help and being patient.
01-28-2010 12:10 PM
You may need to use the Deploy library invoke node to deploy a library from and .exe.
I think the .aliases file is to an .exe what it is to the project. So MyProj.lvproj as an alias file called MyProj.aliases. If you make an .exe and call it MyExe.exe from that project, you get a file called MyExe.aliases. I think you'll just have to do what it sounds like you did which is edit the .aliases file to point to the other computer once you copy it all over from one to the other.