billysmithde2

MrPLC Member
  • Content count

    65
  • Joined

  • Last visited

Community Reputation

1 Neutral

About billysmithde2

  • Rank
    Sparky

Profile Information

  • Gender Male
  • Country United States
  1. Controls with no travel jobs

    End user is the way to go. I used to have a job in a plant as the controls engineer and though it is true much of the work is outsourced, I can say I decided what work was sent to an integrator. I chose who/what/where/how, so could keep some projects in house as desired, and brought in help for the rest, with way too much work for me to do by myself. However, you will still be architect/project manager for the outsourced work because maintenance ultimately falls on you, especially at 2am on Sunday morning... However, it's never zero travel - we used to have production lines moves between US / Europe / Asia. Guess who was always on the transfer team? The controls guy. Guess who gets to spend several weeks on site in Asia while the new line is brought up? The controls guy. At least the pain is shared - the process engineers and managers where always there too. 60% is a lot, and if you do that make sure compensation is appropriate. Even 30% with a wife/children is demanding. Some people can do it, but I have seen what a heavy travel schedule can do - your become a guest with your own family when home. Not good. Some free advice from a mid-career engineer (i.e. somewhere between 40 and 50...) - do your traveling while your young. It doesn't get any easier, as I write this from somewhere in western Europe...
  2. EIP Simulation

    Not precisely what you are looking for, but there are some ideas here: http://www.plctalk.net/qanda/archive/index.php/t-74042.html I'm with Ken - leave IO control to products that support it. Work around it at your own risk. Your time is likely best spent on real hardware as well, unless you have some of these items readily available already, and know how to use them. Codesys has a Raspberry Pi capability that supports EtherNet/IP as adapter, so by definition any class1 adapter will also support some explicit messaging. It's required to just get the class1 connection setup. You may be limited to reading things like IP address, but if the goal is only to read something, it may be enough. Check the supported objects and go from there on the platform you choose to test on.
  3. If I recall correctly, the 6634 has a USB connection for programming. Did you try that? Your attempting to change the IP address of the device which is fine, but I assume you are also changing the IP parameters of your PC with Unity to be subnet compatible? If not, that could certainly be one of possibly many problems. The sure fire way that I use to get the IP off a Schneider PLC like this is to run Wireshark and reboot the PLC. The device will issue a number of gratuitous ARPs and ARP probes on boot up while it performs IP conflict detection, of which we can then pick up the IP. I would run this on the host - not sure if you are in bridge or NAT mode, so don't entirely know what will happen. I have used Unity through a VM so I know it works, for me better with the Ethernet option than any other. I find the pass-through option always to be a little less stable, such as with USB direct or USBtoSerial.
  4. To turn WindowsXP into a router - try something like this: http://www.wikihow.com/Enable-Windows-XP-Routing I never use Internet Connection Sharing so not sure what it does. Likely some sort of SRC-NAT mangling. Other options include using RDP to do a remote session on PC1, and then go in that way. With routing enabled on PC1, on PC2, you might do route add 192.168.0.0 mask 255.255.255.0 200.200.200.x where the 200.200.200.x address is for PC1 (and assuming subnet size). Also on your control equipment, you will have to set PC1 as the default GW. Otherwise, packets can get in, but they will never be able to get out. This can be fun - changing all your control applications and configurations to support a default gateway. If you can't do this, or don't want to, the only other option is something like RDP or VNC, as mentioned, or some DST-NAT behavior. If you are going the NAT route, I would then look at some hardware.
  5. It can be done, but it would not be an architecture I would want to install. If some other group is responsible for PC1, PC2, and company network, they may not want you to do this. Can-do and should-do are not the same thing. Anyway, to address can-do, you would configure PC1 as a router - trivial in Linux, but assuming your running Windows, it will do it as well with a registry change/reboot cycle. I avoid doing this, but have in the past, in a pinch, when needed. Add a static route on PC2 that basically says... to get to the control network, I need to go through PC1. Of course, proper ip address schema must be in place, security considerations, etc.... If you provide more specifics, actual route add commands and the like could be generated to provide more detail. There are other clever ways with NAT and other technologies as well that can be used to hook the networks together but there always trade-offs, most of all with complexity and hardware requirements. In your case, likely nothing extra would need to be procured. The proper way to do this is to work with your IT group to integrate the control network into the corporate network through a DMZ and router, protected by (a) firewall(s) with strong access controls.
  6. Yes, this is done all the time. The key technologies to research are: 1. Router 2. Firewall 3. DMZ (for demilitarized zone) This is mostly an IT thing - are they going to help you set it up?
  7. I have used the OpENer stack in the past and it works well. It is designed to be a class 1 target/slave/adapter implementation (for implicit communications), but of course has to support explicit messaging as a server as well. It probably would not be that hard to add client and/or originator functionality if you are a programmer. Another free tool without source is http://www.molex.com/molex/common/staticLoader.jsp?fileName=/mx_upload/superfamily/iccc/EtherNet_IPTool.html You will certainly need the various volumes of the ODVA standards, Volumes 1 and 2 for sure if you want to do Ethernet and extend the code base. These are not free - you need to be an ODVA member to get them. I know this code has been through the EtherNet/IP plugfest event held by the ODVA for cross-vendor interop testing. You can point a Rockwell Control or Compact Logix at this stack and have it work. It will not, out of the box, support talking to IO, drives, or whatever. It also works with the Schneider Electric EIP modules that are part of the various PLC platforms. Compiles fine on various Linux platforms, including ARM implementations. Says it supports Windows, but I never ran it on that platform.
  8. Urgent plez. External I/O Cards config

    You need to provide more information. Much more. And if it is urgent, as someone suggested, Schneider support is your best bet. It's possible to read data from another rack with M340, but may require another CPU, or the PRA module. Exactly what do you have for CPU and Ethernet devices? If required, can you swap out equipment, or buy some new parts? Of course you can say no, but then you may not get connectivity.
  9. How to do the I/O Mapping correctly ?

    I would want to see a screenshot of your code. It might be a project setting - bit I'm not certain - Tools -> Project Settings -> General -> Management of build messages -> Overlapping addresses generate... error? warning?
  10. What Cable do you use to program a M340

    The specific version of Unity matters for someone to create a test program. Also the CPU in use matters as well, however, you still have not told us what you are using. There are several models of CPU and you select it when you start a new project. If someone sends you a project, it won't work if the CPU is different than what you have.
  11. How to do the I/O Mapping correctly ?

    Wow! A lot of work.... It's been a while since I messed with any large amounts of DIO on Schneider, but from memory you might want to look up the %IW0.m syntax, where m is module - one move instructions from this input word to the %MW word might handle up to sixteen bits at a time. It could save some time for you if it works. It built for me, but I don't have digital IO hardware to test, only an Ethernet module and an M340 CPU. Someone more familiar might be able to validate this approach since I cannot test. There is plenty of %MW memory - it's CPU specific, but mine will do 32K words. You will have plenty for your IO. I almost always copy my IO, as you suggest, prior to using. This way, external devices do not address the IO directly, but the copy, and this allows some flexibility: you can disconnect the actual IO from the tags used in the logic for testing. My only issue is the repetitive nature of what is shown. If I can, I use arrays and loops in ST to manage groups of things. The fewer instructions I write, the less chance I have of screwing it up, and it makes maintenance easier (for me - many here will tell, and there is some truth to this - that maintenance guys like ladder so using other languages is less convenient for them).
  12. What Cable do you use to program a M340

    1 and 2, depending. What processor do you have? What version of unity pro?
  13. AB PLC data vía C++ function

    Have you seen the Opener open source EtherNet/IP adapter stack? TuxEIP is another package you may like. Sourceforge likely has a number of them to get you started. There are also guides on how to access data from a Logix PLC using EtherNet/IP. Any of these would do - but if this is for production, I would use a kit someone else supports. OPC libraries work too... if it's easier to deal with these middle layers.
  14. MrPLC won't open on a Mac?

    I'm on a MacBook now with Chrome and all is good.
  15. Omron Ethernet IP Error

    OK - not familiar with Omron so they overload the IP address to represent some other protocol address too. They aren't the only ones who do this, and it's not a simple update to classless addressing schemes. I guess that's better than not getting with the times...