ASForrest

Hi all, I have an application where I'm trying to dial in remotely to a micrologix 1100 PLC. I would imagine it can be done, but I'm just not sure how to go about it. I have a Micrologx 1100, a Red Lion HMI, and a 3G modem all connected to an unmanaged switch in the cabinet. The PLC's IP address is 10.10.10.12, and the 3G modem's IP address (on the LAN) is 10.10.10.10. Obviously the modem has an IP address on the 3G network as well which changes every so often, let's for the sake of argument call it 169.123.123.10. So if I'm sitting in my office, my laptop has a wifi adaptor, connected to the office router, which connects to the internet, where i can see the 169.123.123.10 address of the modem in the panel, which can see the PLC though it's 10.10.10.10 IP address. How do I go about directing RS Linx down that path? Also, are the gateway settings of the PLC or modem relevant in this application? I've got a basic understanding of what the gateway address is all about, but I've never had to look too in depth at it. Thanks!

ah, that makes sense. Thanks Ken. I've given that info to the IT guy and he seemed to follow. He's set up port forwarding so the modem forwards any traffic received on port 44818 to 10.10.10.12 (the PLC). However, running the TCPing on that port, I get "Socket is not connectd (10057)". I get a reply if I ping on port 80, but nothing on 44818. Any idea what that this could mean? Edit: I've tried TCPing'ing port 789, which is the port set up for remote access to the HMI, and I get a response from that port as well. Still nothing from 44818. The IT guy says he's set the ports up exactly the same way (changing the forwarding IP address and incoming port number, of course). Is port 44818 definitely the right port for a micrologix 1100? I found reference to it in the 1400 manual, but can't find anything about port numbers in the 1100 manual.

Thanks, that's starting to make more sense. I'll have a chat to the IT guy and see if he understands it :) We don't need a constant connection. The application is a chemical dosing system. Every month, the chemical supply company dials in, checks tank leves, chemical usage etc, and send out a truck to resupply the customer when required. Occasionally we need to update the PLC program as well. So we're not needing to be online all the time and consistently, just from time to time long enough to read some values and maybe download a new version of the PLC program. We use a tracert command to find the IP address when we need to log in to the system. Up until recently, the customer has been using some horrible Eaton PLC to do the job, and tunnelling in via the HMI over a virtual serial port to do updates.

side note: I just downloaded TCPING but when I runt he application it very briefly opens a command prompt window then closes it again. Am I missing something?

The modem setup is somebody else's domain, so I'll have to speak to them. I'm not really familiar with how that side of things works, but if I tell them they need to set up port forwarding to port 44818, will that be enough information for them to do what needs to be done? When I say "The IP address changes from time to time", I mean it uses DHCP to connect to the provider's wireless network. So the address it uses to connect to the internet might be 169.123.123.10, and every time it drops off and reconnects to the internet due to a power cycle or something, it will be assigned a new IP address. Then the physical ethernet port on the modem has a static IP address: 10.10.10.10. I would assume (although again I'm not completely up to speed with this) that the modem is acting as the gateway from the internet to the local 10.10.10.xxx network. Anyway, assuming I get port forwarding set up. If I set up an ethernet driver in RS Linx, assign it to my wifi, and add set an IP address 10.10.10.12:EIP, how will RS Linx know where to find 10.10.10.12? I would have thought that somewhere I'd have to tell it to go looking at 169.123.123.10 (or whatever) as the gateway? The modem is always connected to the internet; I believe it needs a password to log in to it. If this will pose further complications to the setup we can disable the need for a password temporarily; it's not a complex or sensitive system, it's just that it's in the middle of nowhere and it's a pain to have to drive 8 hours to make a program change.

brilliant, thanks for that

Hi guys, I'm trying a new programming technique I haven't used before in RSLogix 5000, and my PLC is still 2 weeks away so I can't test a part of the logic. Just wondering if anyone can tell me how the following would behave. Essentially, this part of the application is a blower that blows product into one of 8 silos. Each silo has a valve on the top that when ON will divert into it's silo, and when OFF will pass through to the next. What I've done is created an add-on instruction called VALVE. I have then created an array of 9 VALVE's (9 rather than 8 because there's no Silo 0, so that's just a dummy). The valves tags are Infeed_Valve[0...9]. If I wanted to open the valve for Silo 5, I turn on Infeed_Valve[5].AutoOpen. The operator enters the number of the silo they wish to fill into the tag Destination, and I then use a tag in this manner: GRT Destination, 0, OTE Infeed_Valve[Destination].AutoOpen (if a destination other than zero is selected, activate the AutoOpen of that number's Infeed_Valve). At the end of that sequence, the destination will be reset to zero. My question is: will the AutoOpen for that valve be turned off? It was only a momentary bit, not a latching bit, so from one angle I think having removed that logic, the bit should be turned off. However, from another angle, I realise that I removed the OTE instruction referencing that particular valve while it was on, so with no logic to turn it off, it would probably stay on. Can anyone tell me which of the voices in my head is right? Thanks! :)

The Operator Interface doesn't allow the operator to select an invalid destination. In any case, the last silo in the line doesn't have a divert valve - if no valves are activated, it will end up in the last silo.

Your assumption is not quite right. The AOI reads the AutoOpen bit, processes other logic, and if conditions permit (e.g., in auto mode, process interlocks OK, not faulted...), writes to an output parameter qOpen. I think you might also slightly misunderstand how I've created the AOI (or else I misunderstand YOUR comment) - I've created an AOI called VALVE that controls only one valve, then defined Infeed_Valve with data type VALVE[9], so now I have an array of 9 of these VALVE's. These things being the case, I don't think your suggestion would work. However it probably would if it was the LAST rung - if the LAST rung of my AOI was always on "OTU AutoOpen", then it would process the AOI logic, then turn that bit off. If the external logic is still there to turn AutoOpen back on, the next scan of the AOI would be processed with it On. Once that external logic disappears, it will process one more scan with the AutoOpen bit On, and then the next scan it will have been turned off. In any case, thanks for the response, that gives me a good workaround if the bit DOES stay latched on. I'm still curious to know whether or not it actually WILL stay on or not though, if anyone knows or has a handy test bench set up ;)

well a month later I've finally gotten around to trying it out; it worked a treat with VMWare Workstation :)

Hi all, I've recently started using VMWare to do a lot of my programming, because a lot of the older software doesn't support anything above windows XP. I'm having an annoying issue with the networking and wondering if anyone has a solution? Basically, VMware is running on my Windows 7 laptop. It has a WiFi connection to my office network and the server, where I store all my files, and also access to the internet. When I want to communicate with a PLC, I plug it into the the LAN port. Now when I'm using the host machine, this works fine - I configure the wifi to use DHCP and the LAN to use a static IP and everyone talks to everyone else and everyone is happy. However, in the virtual machine, XP only recognises ONE network connection - a LAN connection. Using the virtual network editor, I can configure this to look at either the wifi, or the LAN connection (or "automatic", in which case it appears to choose wifi as that's where the internet is). But this is a huge pain, as when I finish working on a project and am ready to download, I switch to the LAN, reconfigure the network to use a static IP, connect to the PLC, and then realise that all my files are on the server, which I am no longer connected to. Is there a way to make XP recognise a separate network connection, and to get VMWare to link the LAN to one, and the wifi to the other? Thanks guys!

awesome, thanks Greg! I've been away and haven't had time to try it out, but I'll give it a shot this week and let you know how it goes :) Cheers!

Hi all, I've been having painful issues trying to download to a few older AB devices over serial. I'm using a USB to serial adaptor thats supported by windows 7 and all but my downloads keep failing halfway through. On one PVP400 it took over 20 attempts to successfully download, and the download took around 90 minutes (on a very basic, black & white, non-touch-screen display). After talking to a few people about my problem, they're all telling me the same thing: basically that Windows 7 is the devil and I should be running a virtual machine with XP. Can anyone else confirm their suspicions, or offer any other advice? If I'm going to go the way of a VM, I don't have any problems with ethernet comms on windows 7, so for ease of use I'd prefer to stick to windows 7 wherever possible. But if I need to use a serial driver to communicate with something, I'll need XP. Working out rockwell activations does my head in, but is it possible/practical/doable to have all the activations running on my laptop - not a dongle - and be able to access them in both windows 7 and VM windows XP? Also, does anyone have significant experience running VM's on Windows 7 that can tell me which ones to go for and which ones to avoid like the plague? Or what my laptop specs will need to be to run VM's successfully? I'm running Windows 7 Professional 32 bit, 4GB ram, 2.1GHz Dual core. Thanks!

Thanks guys. I've used VMWare before and found it to be quite stable (once it was set up right), although I wasn't involved in setting it up before, so I might have to take a crash course :) will I need to upgrade my ram/upgrade to 64 bit or is that just a nice-to-have? I need it to be pretty reliable, but (hopefully) the VMWare will just be my go-to in case of serial or strange annoying problems, I don't need to be running everything through it.

ahhhhh yes, that's what I missed. the attribute I was looking at within the WALLCLOCKTIME was DateTime, not LocalDateTime. Thanks!

Hi all, I've got an issue with a WALLCLOCKTIME command. It appears to be tracking to UTC - when it returns the data it gives me everything correctly except the hours DINT is 10 hours behind. Not so coincidentally, my time zone is UTC+10 hours. When I change the time zone on the controller, even though the time displayed in the controller parameters window changes, the DINT from the GSV doesn't. I don't think I've done anything any different to how I've done it before - although I have just updated the firmware on this PLC to version 20, and there was a popup when I did that mentioned synchronising times to UTC. Unfortunately, I didn't pay as much attention as I probably should have done to what it said, but either way I'm suspecting this is something new to FW version 20. Does anyone know how to change it so that it tracks local time instead of UTC time? At the moment I've just rolled the clock back 10 hours, but that's really not an ideal solution. Cheers :)

Hi all, I've got to update the firmware on a 1769-L32E controller this week from version 15.4 to version 20.11. I've done firmware updates before, but only ever on a new PLC. This one is in an existing plant, with several other PLC's and a HMI talking to it. I noticed in the release notes that it says that all the other PLC's trying to read/write from it must be disconnected from the network or stopped before updating the firmware to prevent ethernet traffic getting in the way. This is not an option for me as the rest of the plant needs to continue to run. There's an ethernet switch in the cabinet I'm working in that has just the PLC and the HMI connected to it, so I figure if I disconnect the incoming network cable and the HMI network cable, that will stop anyone talking to the PLC. So a basic question - if I have just the PLC and my laptop plugged into an ethernet switch with no incoming network cable, can I still see the controller on RSLinx and download the firmware over ethernet? Also - is there any other snags or hints I should be aware of before starting this process? Any issues with such a large jump in firmware revisions? I appreciate any insights - I'm still on probation on my new job so I'd prefer not to shut down a customer's factory if I can help it

Well everything went more or less according to plan thanks for the advice everyone, it's much appreciated. "why must it be upgraded? ... what new functionality do you require? ... " Primarily, Add-on instructions. I have several pre-built AOI's for various applications, and being able to use them probably saved me 3-4 hours programming for this job. I guess I could have copied and pasted the logic but that still means going through and creating individual tags, and to me it just looks unnecessarily complicated. "depending on how much is at stake (measured in money or in reputation) you might consider getting ANOTHER processor and setting that one up with the firmware – and downloading the upgraded project ... once that's been set up and safely checked out in a "bench test" arrangement, you should be able to physically swap it with the existing processor in just a matter of minutes of downtime ... and if something should happen to "go wrong" (unexpected loss of communications with the rest of the plant's systems for example) – you should be able to quickly reinstall the old processor and get things back on track again ... once everything has been working correctly for awhile, upgrade the old processor and keep it as a spare ... " I wholeheartedly agree, that's what I've always done before and ideally what I'd have done again. It's really just a case of, I've just started a new job in a smaller contracting business that hasn't branched into the programming side of things much before, so it's my job to help build that side of the business. At this early stage in a smaller business it's hard to justify the cost of having extra processors sitting around, especially when for most of our jobs, the PLC gear is supplied by the client, not by us. Hopefully once we've started to develop things a little more and I've established a solid reputation here I'll be able to convince them it's worth the extra outlay Thanks again!