02-05-2015 02:39 PM
I have created a LabVIEW application using LabVIEW 2012 (64 bit) that attempts to communicate with a PLC. I do not actually have the PLC here at the Rockwell Collins facility in Cedar Rapids, Iowa.
I have sent this application to my co-worker, who is located at a different Rockwell Collins facility in Tustin, California, where the PLC is actually located.
My coworker in California is reporting that when he starts up my application under WIN7 he gets an error code of "-251723766" when the S/W performs the "Open Session" function during initialization.
I looked at the online help and the value "-251723766" is not defined.
When I run the same application under WIN7 here in Cedar Rapids I do NOT get the runtime error code of "-251723766" during initialization.
Do you have any ideas for what is causing this problem?
02-06-2015 03:50 AM
Hi tjmiller,
I have never met that error. I'm wondering since you mentioned the error happens during Open Session, it could be caused by something like NIC binding?
Would you please show some parameters for the open session vi, at least? If it does not violate your privacy, posting a reproducible snippet would be better.
02-06-2015 07:40 AM
Hello
NIC binding or something like that is a likely cause of this problem.
The other thing that crossed my mind as a possibility was the Windows firewall.
I have attached 2 JPEG files that show what I am doing in the LabVIEW block diagram to call the open session.vi
I have no problems with the open session.vi when I run my application here on multiple computers in Cedar Rapids.
As you can see from the attatchments all I am doing is calling open session and passing it a constant of type session.
Any suggestions?
Thank you
Todd J. Miller
Rockwell Collins
Flight Control Systems
Cedar Rapids, IA
319-295-8689
02-06-2015 09:25 AM
Hi Tod,
You intend to reuse a session? I may not have understood the way you are using session. Session can be open "implicitly" when you call create assembly.vi, so unless you are reusing it, I don't suggest you do it that way.
I don't see the exact parameter in your screenshot, or where those global variable go. So I can not tell what's wrong. For NIC binging in the session, you may have configurations like this - "IP:LocalIP=192.168.0.1" as the session terminal content to specify which NIC to use.
02-06-2015 03:03 PM
Hello
I never really understood what the session parameter was all about.
The documentation says that the session parameter is optional.
Based on your advice I have deleted the code from my block diagram that was doing an Open Session.
Are there any example LabVIEW programs that I can study that actully use the Ethernet/IP S/W to connect to a PLC?
I have attached 2 screen captures that show how my LabVIEW VI's are accepting the session parameter.
Do you think I should delete the input and output parameters for session?
Please let me know.
Thank you
Todd J. Miller
319-295-8689
02-08-2015 08:10 PM
HI Todd,
<National Instruments>\LabVIEW 20XX\examples\ethernetip\ has all the examples that come with the EIP toolkit.
From your screenshot I still can not tell if you intend to reuse sessions. (because you pass a global session parameter in). If you do not, you can try to delete them.
02-13-2015 09:12 AM
Hello
As you suggested in your previous posting I modified my LabVIEW S/W to not use the Session parameter.
I believe this has made a big improvement.
We are now getting error messages when the LabVIEW S/W runs but the error messages are totally different.
We are no longer getting the error message that says "Unable to connect"
The error messages we are getting now say "CIP Error" as shown in the attached screen captures.
Please look at the attached screen captures.
Do you agree that we have now progressed to where we at least have basic low level communication working with the PLC?
Can you give me any advice on what the error messages are trying to tell me?
Thank you
Todd J. Miller
Rockwell Collins
Flight Control Systems
Cedar Rapids, IA
3190295-8689
02-14-2015 08:04 PM
Hi Todd,
From the error message, I'm thinking whether you are running VI and the PLC programming environment on the same PC. If you are, VI would not be able to communicate with PLC because the EIP port would be occupied.
Aside from that thing to check, I think if you could extract the erroneous part of the VI rather than debugging the whole project, it would help a lot. Can you show what's on the block diagram in that case?
Also FYI, boolean type on these series of PLCs is actually a DWORD (32-bit), and you access them as a whole and then access the bit you are interested. So on PLC side you have this array of 32 boolean which is actually a DWORD, and on VI side, you can refer to the EIP example Write And Read Tag.vi.
02-16-2015 08:32 AM
Hello
Per your suggestion I have sent an email to my co-worker out in California to ask him if he is running the PLC development tools on the same PC.
I have also attached 2 JPEG files to this posting that show the block diagram and constants of the VI that is generating the error messages shown in my previous posting.
As you can see essentially all I am doing is calling the NI provided VI named "EthernetIP Tag Write.vi"
Also as you have suggested I created a new .exe file that just tries to write a single boolean to the PLC.
I will send this new .exe file to my co-worker in California and ask him to run it.
I agree that it would be good to simplify this problem down as much as possible while we are in troubleshooting mode.
My understanding is that it is possible to ping the PLC from the PC that we are using out in California.
I believe this shows that the H/W is configured correctly to allow basic Ethernet communication between the PC and PLC.
Please review the attached JPEG's and let me know any suggestions you might have.
This problem is literally holding up a million dollar project here at Rockwell collins.
Thank you for your help.
Todd J. Miller
Rockwell Collins
Flight Control Systems
319-295-8689
02-16-2015 09:03 PM
Have you got any answer from your co-worker yet? The ping command working does not rule out the possiblity of running both VI and the PLC development tools on the same PC.
What the screenshot shows looks normal, and unknown for those unrelated to EIP. It is not an extraction of the buggy code, is it.
I think the answer / result from your coworker could be more informative.