Gary.Johnson

MrPLC Member
  • Content count

    41
  • Joined

  • Last visited

Posts posted by Gary.Johnson


  1. On 11/13/2020 at 3:33 PM, Michael Walsh said:

    ETN21 has an entry for default gateway.  I cannot upload the image for some reason, but it is there. 

    Not sure if it's too late to help with this but setting the default gateway in the ETN21 is different from the EIP21.

    The EIP21 has a dedicated spot for the gateway address. In the ETN21 you have to add an entry in the IP Routing Table. Set the IP address to 0.0.0.0 and Router's IP Address to the address of your gateway.


  2. Got an interesting question a bit ago. With the COVID19 scare going on our operators want to start cleaning touch screens with a 29% Ethanol/water mix. Our facility uses Omron NS and NTs and a handful of TCP Quickpanels and Profaces. The manuals I've found say weak solutions of solvents are acceptable but don't say what the OEM considers a 'weak solution' to be. Anyone tried cleaning an industrial touch screen with Ethanol?


  3. Those symbols can mean different things depending on where they are used. If you have a CJ or CS series PLC, Omron manual W394 explains how to use them.


  4. OK, found something else to cry about. Consider the following:

    Project includes EIP network so addressing is through network tags (arrays). Each device on the network gets its own array/tag. I add unique comments for each address associated with a given device. When I use any of the addresses in the PLC, whether entering as array[index] or typing the literal address directly, CX-P displays the tag name/comment instead of the unique comment associated with the individual address.

    If I want to see address specific comments I have to use a XFER block to copy the tag/array into a parallel set of addresses and attach the comments to the parallel addresses. Very wasteful in terms of memory, program size, and time.

    It would be swell if CX-P gave priority to individual comments and only showed the array comment where there is no comment attached to a particular address.

    Example attached.

    EXAMPLE.cxp


  5. On 2/14/2017 at 1:19 AM, kaare_t said:

    Just FYI: Ports are layer 4 in the ISO stack model, and layer 3 in the TCP/IP stack model. This basically calls for a router and not a managed switch.

    Managed switches (L3) deals with MAC addresses and are able to do e.g. VLAN translation and/or policy-based forwarding. They are generally not designed, nor will do any kind of port translation/forwarding. This is what routers are designed for. General firewalls normally have port related functions built-in, so I would start with looking for a good, industrial firewall (not sure what exists in the U.S. though).

    Thanks kaare_t,

    One of the things slowing my search is filtering the verbiage. Some folks think of a 'port' as the physical hole you plug a patch cable into, others think it is an attribute of a logical address. Some suppliers offer 'Layer 3 switches' where others call them routers and some offer 'routers' with no (TCP/IP) layer 3 capability at all. I end up having to download the manual or tech spec to identify the specific capabilities and protocols the device supports. Very time consuming.


  6. Got it sorted out. "Implicit messaging" is ODVA's term for mapping memory areas of a given device to Devicenet master allocations. In the case of the Watlow devices it's a list of parameters like presets and temperature readings that are mapped to DRM21 addresses in order of appearance. The first parameter in the list is mapped to the first allocated address and so forth. Watlow provides a piece of software called ASSEMBLY PROGRAMMER for configuring their devices and you have to have it to use their temp controllers. The units as delivered can't be controlled over Devicenet. I suspected this but the manufacturer of the machine I'm working on mucked things up so badly that it was impossible to tell from his code. The fellow I spoke with at Watlow was an expert on their devices and how to configure them but wasn't much help trying to translate that into Devicenet. I had to configure a device, add it to the network and sift through PLC addresses until I stumbled onto the numbers I was looking for. Time consuming but it got the job done. Thanks again. Hope this helps the next guy who runs into these devices.

  7. Thanks PdL, I did that when I was initially handed the system. The device(s) in question are Watlow EZ-Zone temperature controllers. The configuration in the DRM21 allocates four 8 bit registers as polled inputs and four 8 bit registers as polled outputs to each of the Watlow nodes. The EDS file supplied by Watlow shows 80 bytes one way and 84 the other. Some of the controllers are dual channel and require a minimum of 16 bytes in each direction to exchange the minimum information required to operate them. This leads me to believe that the configuration in the DRM21 has no bearing on CIP implicit messaging. I guess the next question I have is does this CIP implicit messaging operate independant of the I/O configuration in the DRM21 and if so, is it possible to (re)configure the devices to operate like normal Devicenet nodes or do I have to figure out how to exchange CIP implicit messages?

  8. Got a real head scratcher and I'm hoping for some guidance. I've been handed a system that communicates with field devices over Devicenet but instead of reading/writing CIO addresses the PLC and devices are exchanging hex codes via something called "CIP implicit messaging". I've pretty much figured out what CIP messaging is but the OEM didn't bother to provide a map of the specific addresses in use. I'm looking at an overcomplicated chunk of programming that employs multiple levels of indirection (for loops, index registers, pointers, arrays...) and no documentation to explain how everything works. Before I spend days/weeks trying to pry information out of the OEM or reverse engineer the entire system I'm hoping there is some sort of correlation between these CIP message addresses and the CIO addresses allocated to the nodes in CX-Integrator. Any insights?

  9. Got a project with 100+ screens and the supplier wasn't a very good speller. I need to correct a spelling error on 1200+ buttons and labels. I've read thorugh the CX-Designer help file and manual and can't find a search/replace for text, only addresses and tags. Am I looking in the wrong place or did Omron actually forget to include this?

  10. Any chance your W bit is mapped to an input somewhere (Devicenet, Profibus...)? Happened to me once. Contractor fat fingered something and moved half the I/O table. First symptom was work bits that weren't working.

  11. Got into a discussion the other day regarding my company's practice of storing documentation (ring binders) and spare tooling inside the main (high voltage) enclosure. It's my understanding that anything that won't fit in a print pocket on the door has to go somewhere else not only for house keeping but also for fire safety. I would like to base my argument on a regulation or documented 'best practice' but I've yet to find one. Anyone aware of a reg/rule covering this?

  12. I made a template (.xlt) file with one tab for bit level comments and symbols. Another tab is formatted with 0 decimal places for word level (DM/HR/Channels) stuff. A shortcut to that template sits on the desktop. Saves time and frustration.

  13. I'm seeing the opposite. D/L speeds from 10-60KB/s. Took more than two hours to download the April updates. It's the age of Gigabit Ethernet and Omron's update gizmo acts like it's on dialup.

  14. Howdy all, My latest quandary revolves around setting the background color of screen objects (labels) remotely. I'm doing this by stuffing numbers into DMs and it works fine. The problem is I don't know which numbers to stuff. I've torn the Omron documentation apart and can't find anything. A search of MrPLC didn't turn up anything either. Anyone know the code?

  15. The communication problem I've been fighting has spread. The affected ports are 100% inop. What I've seen leads me to believe the problem has to do with the USB adapters and the way Windoze assigns serial port numbers. Based on this, I'm confident that CX-One is not at fault. I guess that means this thread has run it's course. If I ever find a way to untangle the com port numbers I'll post it here (and several other places as well). Thanks again to everyone who offered advice. If not for you I'd still be scratching my head and cursing CX-P.

  16. When I try to use one of the scrambled up ports the only response I get is the "Failed to connect to the PLC" dialog. No usable info there. If the adapters stopped working completely I would suspect them but every one of them works with everything but CX-Programmer. I'm working with Michael at present. He's referred this to Japan as they are the only ones who know what really goes on in the guts of CX-One. In the mean time I'm going to re-run all the experiments I did last month to see if I missed anything. I'll let you know if any breakthroughs occur.