kaiser_will

MrPLC Member
  • Content count

    918
  • Joined

  • Last visited

Posts posted by kaiser_will


  1. Give this a try.  You are going about it in the right way...get system communications up first.  After that, create a simple HMI program with a display lamp tied to a PLC output and a button tied to a PLC register bit, then add a simple PLC program with a rung utilizing the 2 elements.

    Work_Instruction_-_Allen-Bradley_1747-PIC_Driver_Install[1].doc

    1 person likes this

  2. The task...for the HMI to display technical documents.  What HMI model or SCADA system are we talking about?  What form are these technical documents in?

    The PLC side of this should not be an issue as the technical documents would need to reside on the HMI or SCADA PC.

    The function you are describing is HMI spawning and displaying a technical document (PDF or Word) within a HMI screen.  If SCADA PC, PDFs can easily be spawned and displayed within a page via an Active-X plug-in.  The big challenges with SCADA PC is that the engineer would be responsible for linking the latest documents.    


  3. You are asking, if you have a PLC UDT configured already, can the HMI add tags to this PLC UDT array?  I do not believe this is possible, as modifying a UDT (adding/deleting tags,  modifying the UDT array size) requires a PLC program download to take effect.

    What you can do is structure your UDT array large enough for future possible expansion, add HMI ability to edit the array, and code the an end-of-list pointer.  Add HMI ability to edit the array, such as adding a new part to the list (which would shift the end-of-list pointer).  If you run out of array size in the future, simply expand the array size and download.

    1 person likes this

  4. FTViewME (HMI version) can store data, internally, but getting the data out (and getting out in a usable form) are a chore.  If you have a Rockwell support login, there are links in this forum post to take you to the Rockwell freeware that can convert the machine coded data log file to Excel.

    http://www.plctalk.net/qanda/showthread.php?t=49903

    FTViewSE (PC version) gives the user the same functionality of FTViewME but with added ability to store historical events and data.

    It comes down to features desired and budget.  If your organization wants automated emails sent out every data with archived data...a HMI will not work; if your organization is OK with someone removing a data log card from the HMI and manually converting the machine code data to Excel...you will need a Rockwell support login to download the freeware program.

    A FTViewSE application can never be downloaded into a FTViewME HMI (or vice versa).  Separate programs, separate licensing, different hardware platforms.  Rockwell develops Product Profile brochures that boil down the basic features and differences.

    http://literature.rockwellautomation.com/idc/groups/literature/documents/pp/ftalk-pp012_-en-p.pdf

    http://literature.rockwellautomation.com/idc/groups/literature/documents/pp/ftalk-pp013_-en-p.pdf


  5. Yes...when you copy a HD contents to another hard drive, the FTActivationManager license file will need to be re-activated for this new hard drive.  BEFORE you pull the old drive out, startup FTActivationManager and get on the phone with Rockwell license service; then after the hew drive is in service, you will have to do the same procedure to check in the license and activate.

    1 person likes this

  6. There are a number of ways to do this...a SEC timer (0-59 sec) that one-shots a CTU register (MIN), with limit test branch to one-shot a CTU register (HR) and to clear, also with a limit test branch.  Make sure to put limit tests in to keep from rolling over the registers and causing the processor to fault.  

    You can also utilize the processor's System tags for date/time.

    1 person likes this

  7. Have you tried to use WireShark and study to interpret packet transfer?  Turn off all ports and communication connections on your WireShark PC except for the port connected to the PLC/Drive network, setup WireShark to monitor, let it run for time, stop and save the file, then go back through.  After awhile you will get a feel for the PLC/Drive connections in the WireShark report.

    If you can procure a spare PLC with a network connection, you can code on both ends reading and writing of time/date with heartbeat tags.

     


  8. PCMCCARTNETY1 makes a good suggestion.  If you pursue this you will need to buy RSLinx OEM to create an OPC connection to the PLC.  Free RSLinx will not suffice.

    And the suggestion of Sytech or Crystal Reports is spot on.  You will probably find when you complete the task of getting the data that members of your organization will want structured, periodic reports.  Both of these packages are very straightforward to setup and configure the tags you want to pull data from and the report options you desire.


  9. You have a FTView ME application and you want to archive the data?  This really is the purpose of a FTView SE application (HMI visualization of a ME application with ability to archive historical data and events).  Keep in mind that the HMI data archived in SE is stored in machine form; if one desires to have data ported to an external file (XLS, Access, SQL), a historian is needed like FTView Studio.

    Questions before you make a data archiving move...how many points of data do you want to store, what types of data points (string, analog, digital), how often do you want the data stored, what is the budget, who will look at the data (dig into the database and poke around, or have the system push reports such as daily or shift reports).

    FTView Studio is very, very expensive.  Excellent for archiving data from more than one process.

     

    1 person likes this

  10. Some students post here for the quick answer.  

    With NO proximity sensors, these would be coded in parallel so that any energized will energize your alarm coil.

    With NC proximity sensors, these would be coded in series.

    To get the flash rate of the alarm coil to match the proximity sensor, you will run  into issue if more than one sensor is made at a time.  You can work around this by coding a routine that will cycle through the alarm codes with pauses or fast pulses in between alarm code display and a different pause or fast pulse when cycling through.

    My suggestion is a state-based routine; use a state register; rung 1, state 10, if this then that and move to state 20; rung 2, state 20, if this then that and move to state 30.  With state-based routine you can easily add code to get the desired results and make the routine robust and functional.

    1 person likes this

  11. We put forth extensive research into a similar ControlLogix issue 2  years ago in which we were pushing the execution of AOI's and getting varied results.  The fix...instead of an AOI used throughout a fast-scheduled routine (4 x 16 AOI blocks), we put all of the code in a single AOI with a fast-scheduled program that had one rung referencing the AOI.  This was an issue we had brought Rockwell into a number of times.  In our case, we were intending to migrate from a PC-based system to ControlLogix and needed our fast routine to execute every 1-2 ms.

    1 person likes this

  12. A simple flowchart, here, will help you design the circuit.  So you have (1) output - a PLC output energizing a fault lamp; with (8) inputs - proximity sensors.  You want PRX1 to flash the output once-pause; PRX2 to flash the output twice-pause; etc.  

    ?1. Do your (8) proximity switches have normally-opened (NO) or normally-closed (NC) contacts.  

    ?2. How should the fault lamp output behave if (2) or more fault proximity switches are made.

    Yeah, you will not find an example of this in literature as this is a PLC ladder logic or function block or structured text programming example.

    Is this a class project?


  13. I would encourage you to stay away from the Kinetix 300 servo controller and move towards the Kinetix 350.  One serious issue we ran into is that the extreme limits are configured NO (i.e., extreme limit gets damaged and potential exists for the mechanical apparatus to run off of the rails).

    Along the same line, the MicroLogix 1100 does have an Ethernet/IP port, but much like all Logix500-based controllers, networking is for peer-to-peer messaging.  A CompactLogix that supports coordinated motion I would highly suggest.  Keep in mind that CompactLogix and ControlLogix controllers both utilize Studio5000 (Logix5000 before Rev. 20).  The coordinated motion function blocks of the Studio5000 series are very straightforward to code and get into operation.

    For myself, the Advanced Studio5000 and Advanced Motion classes by Rockwell have worked for me.  There are other forum members who have designed similar hands-on or literature-based training.  With the Rockwell courses that have labs, the lab instruction book you receive is a great tool to go back to re-visit "how did I make that work?".

    Additionally, Rockwell packages many of these classes into smaller classes that they offer at their On The Move shows that are offered regionally.  These are shorter classes that are usually FREE.  http://www.rockwellautomation.com/global/events/raotm/north-america/overview.page? 


  14. It is possible the Schneider VFD displays Modbus addresses as Hex, and the A-B PLC displays Modbus register addresses as Decimal.

    8601 dec <=> 2199 hex

    So keep in mind with Modbus that addresses can be DEC or HEX at one end, and understand the stacked memory registers of both devices.  Modbus is the communication pipeline and all possible memory registers, be they bits or words, is one complete stack.  The device manufacturer designed that device for all inputs to have a section of the stack, all outputs to have a section of the stack, etc.

    Attached is a Modbus Memory Map I created for a Wago PLC - ICP DAS HMI project.  I read the literature, researched Modbus communication and experimented with writing and reading many tags at both ends.  Note that the ICP DAS HMI registers are off from my Wago PLC, the stack is shifted at one end.  If you can monitor memory registers at both ends, you can clear registers on both ends, toggle bits or write data to register words, monitor the other end, and take notes as you go.

    Once you understand the Modbus memory stack and how both devices utilize the stack, you are home free.

    There are some free Modbus tools (ICP DAS Modbus Master Tool is one).  http://www.icpdas.com/products/PAC/viewpac/download/viewpac/download_utility.htm

    Lighting Control Tag List.xlsx


  15. DH+ is a twin-axial cable.  It is not unheard of for the system "to work" with the "blue hose" (typical Belden DH+ cable) not terminated properly.  Then a small change to the DH+ network and intermittent operation occurs.  

    I like to develop Primers or Work Instructions and make sure the technicians have access to (and utilize) the information.  Lessons Learned go at the top.


  16. Modbus is one of the oldest controls communication protocols.  When I configure two different devices to communicate via Modbus, I experiment with Modbus registers at both ends.  Change values and verify reading at other end.  

    I have run into issues before with devices in that one has to shift the Modbus address up or down a register to get to line up.  There aren't many tools I have round for sniffing Modbus packets.

    1 person likes this

  17. So you have (2) DH+ networks, 1st being the local SLC-PV1000 network and 2nd being the plant DH+ network.  One cannot simply connect the 2 together and expect harmony as DH+ is an addressed node arrangement.  Typically, local DH+ networks, such as your SLC-PV1000, would be PLC = Node 0 and HMI = Node 1.   One cannot have two or more devices on a DH+ network with the same node address.

    First, put the (2) DH+ networks back as they were and get them back up and running properly.

    Second, look for a DH+ network drawing (if it exists).  If you cannot find it, then you will want to start mapping out your network.

    Third, read up on DH+ so that you know the rules.  Terminating resistors at both ends, baud rate options, how many drop nodes you can have, length of drop lines, length of trunk lines.  When you touch a working DH+ network to simply add another node, do not be surprised when the rest of the DH+ network exhibits strange behavior.  The strange behavior can easily be unplanned production.

    http://literature.rockwellautomation.com/idc/groups/literature/documents/um/1770-um022_-en-p.pdf

    From my DH+ Primer:

    -          DH+ is a 57.6K or 115.2K token-passing peer-to-peer network for less than 20 devices

    o   DH+ was designed for trunk lines and drop lines

    §  Trunk lines run the length of a network and terminate into drop line drops (1770-SC station connector)

    §  Drop lines run from station connectors to the device


  18. Have you gone online with RSNetworx to analyze the network?  With a error E78, one would expect to see a node or a whole section of the network drop off.  Keeping in mind that a DeviceNet network may be addressed and wired in different manners.  I have seen the network "go to sleep" intermittently from the problem point on.  If you can pinpoint where, which node, the problem occurs at, then look at the nodes before and after, those 2 sections of DeviceNet network cabling is where I would be focused.  

    Things to personally inspect...terminating resistors at both ends of the network (sometimes networks just work then one day then start giving you fits and you find out one resistor is missing or has a loose terminal), damaged trunk line or drop line (dig into RSNetworx to find diagnostic history).

    While you are at it, take a few minutes to go back through your DeviceNet network design.  There have been occasions in which the root-cause of DeviceNet network failure was due to a poorly designed network (i.e., too long of trunk or drop lines, too many nodes on a drop line, wrong terminating resistors, etc.

    http://literature.rockwellautomation.com/idc/groups/literature/documents/um/dnet-um072_-en-p.pdf