BE

MrPLC Member
  • Content count

    63
  • Joined

  • Last visited

Community Reputation

8 Neutral

About BE

  • Rank
    Sparky

Profile Information

  • Country Australia
  1. Mine is definitely set to normal. I haven't worried about trying to work out why it runs slow, mainly because it doesn't really affect my work that much. 
  2. Port 2 looks like it has all the robots on it, all the ECC203's appear to be on other ports. Is that correct? Roughly how long are the EtherCAT cables? are we talking 2-3m (ie. between nodes in a panel) or more like 20+ (ie. connecting nodes in separate panels? Are the cables shielded? Silly question I know, but got to ask  Judging by the screenshot, I would assume you have multiple EtherCAT cables from various locations running back to a single point. I assume it isn't possible to eliminate the JC06 for testing?   Most of my EtherCAT experience is with ECC203's and VSD's in motor control centers, I haven't really used it outside of the confines of a switchboard. That said, I would imagine it would require the same type of installation conditions as regular CAT6 cabling (ie. seperate from power cables etc.) to avoid interference. Would it be safe to say the cables are seperated from power cabling (particularly VSD driven motor cables)? 
  3. Once the system is operating, does the EtherCAT ever drop out, or is it only a problem on startup? Any chance that the JC06 can be removed entirely, even just for testing? I have had one of these fail before, and it caused all sorts of weirdness (I understand that this has already been exchanged) Does this happen every time the machine is power cycled? Are the EtherCAT cables prefabricated? Any chance of posting a network topology to show how things are connected? (ie. are the robots all on one port of the JC06 etc) Is the problem occuring on only one string from the JC06 or different strings?  
  4. The HMI's on the site I did just went back to the PLC via an Omron Ethernet switch (W4S1-05B0), which is just an unmanaged ethernet switch as far as I know. Any chance of replacing the Cisco switch with something else for the purposes of a test? Does this site have firewalls managed by an IT department? I have run into problems with those at times also, particularly if the person using Sysmac Studio is remoting into the PLC. What is the PLC primary task scan time set at? The previous thread indicated (sort of) that it was set at 3ms, but your original post indicated it is running at 3.1ms. Just confirming that it definitely isn't exceeding its scan time.  
  5. I have commissioned a plant with 3 NA5 HMI's (about 3-4 years ago). That site did/does have some comms issues that cause buttons to stick occasionally (see this post for info https://forums.mrplc.com/index.php?/topic/42220-booleans-getting-stuck-on/), but for the most part the system works fine. It is worth mentioning that of the 3 HMI's in that system, one is mounted in the MCC, and the other 2 are between 20 & 40 meters away. These 2 are the main ones that had the problems. In the end I put it down to a bit of interference, this site has a lot of VSD's, and despite all efforts to the contrary, sometimes the power and comms just have to overlap (the implemented fix is described in the post). I never had the HMI's 'freeze' on this site though. Long shot, especially since it seems worse when someone is online with Sysmac, but do the HMI's have any VB code running in the background? I was playing around with this a while back, and had a HMI (simulator actually) that kept "freezing". What was actually happening (as advised from my Omron tech support) was the HMI was waiting for the VB code to complete execution (which took a while because of what I was trying to do), and would not do anything or respond to other inputs until it was complete.
  6. I have done labels in IAG's in the past using a Data Display, instead of a label. This allowed me to display the value of a variable (in this case a string) in the IAG. Each instance of the IAG had a different variable assigned, therefore a different 'label'. Is this the type of thing you are looking for?
  7. Just checked in in Sysmac Studio, Enumerator members can't have the same name as any other enumeration datatype members, including different enumeration datatypes. So if I have 2 enumerators, called Enum1 & Enum2, none of the member names of Enum2 can be the same as the member names of Enum1 and vice versa.  So I would go out on a limb and suggest that ST automatically finds the right datatype name, because member names have to be unique. Does make me wonder why ladder logic doesn't do the same thing, maybe someone else has some insight on that.
  8. I haven't used Enumerators before, but a quick google (youtube is great), and a quick test in my dummy program indicated that when referencing the Enumerator, you need to type EnumeratorName#MemberName So in your case, it would be AOI_In_State#AOIIN_ReadyForTest instead of just AOIIN_ReadyForTest Can't be 100% sure as I have never used them before in one of my programs, but maybe try that and see what happens
  9. Sysmac Studio Improvement Request

    Glad to see I am not the only one who uses random letter combinations typed by my left hand for variable names when testing ideas
  10. The variables you are copying, are they variables inside the actual function block or are they the variables that you are assigning to the inputs/outputs of an instance of the function block in the PLC code? I can't say I have experienced what you are seeing. The only time I had similar problems is when I have: Copied global variables into a program, without them being registered Changed from ST to ladder logic, but haven't used the right function for a given datatype (typically datatype mismatch when comparing variables or similar) When a variable has been registered automatically, but Sysmac Studio can't work out what type it is   If it's none of those, then I really don't know. 
  11. When you say "copy variable names into the ladder logic", are you referring to the variable names that you previously copied and pasted (in/out and internal)? In your variable table in the function block, are their any variables that don't have a datatype?
  12. PLC Law

    I realise this hasn't had any additions for a while. But I thought I would throw in a couple that I use, now that I have had a good chuckle courtesy of everyone else that has posted in here over the years. PLC Rule #63: When tracking down which piece of hardware is causing that really annoying, intermittent problem (which, as we all know, everyone else will be blaming on the programming), don't assume that it is only one piece of hardware. While it is rare, be open to the possibility that multiple parts are faulty. Or the possibility that the problem might have more than one cause. PLC Rule #63.1: If your digital field inputs are causing problems with your programming, even though every other instance of that code is working perfectly, make sure the electrician (or apprentice) wired the field sensor correctly (ie. normally open or normally closed).......   I know Rule 63 doesn't happen very often, but it can happen. I was commissioning a plant that had the VSD's and an Omron Coupler on an EtherCAT network. Worked fine for a couple months. Then the coupler randomly started dropping out. VSD's started dropping out at the same time. And the system wouldn't reset itself without a power cycle. For those unfamiliar with EtherCAT, typically when the device comes back online, it just reconnects, the PLC doesn't need a power cycle. After about 3 days of frustration (because it only happened randomly, so wasting a lot of time standing around trying to make it fault), it ended up being a faulty VSD comms card and a faulty EtherCAT junction. Eliminating only one of the problem parts didn't solve the problem.
  13. NX IO Unreliable?

    So taking the CPU rack for example, you said when you prodded the AD3204 in slot 1 that it failed. When you say failed, did the I/O for that one card drop out or did everything drop out? It really does sound like there are bad contacts somewhere that are disconnecting with slight movement, but to be honest I have never had that problem. And if the CPU cards are dropping out, then I can't see it being an EtherCAT issue. On a slightly different note, it doesn't appear that you have a PF0730 card in slot 1 on the CPU rack. I only raise this as every time I order an NX102 CPU, my Omron tech tells me I need to order one for the I/O supply (for the CPU only, the Coupler doesn't need one), but that Sysmac Studio doesn't show it as being needed. So I take their advice and order one. Now I am starting to wonder if I actually need them........ I wouldn't think that would be the problem, as it has worked fine for ages, but it was just something I noticed. Sorry I can't be of any more help, maybe someone else has some ideas too or chime in if they have seen similar behaviour before.
  14. NX IO Unreliable?

    You say you have 2 racks of I/O cards, I am assuming that one rack is the CPU with some I/O cards and the other rack is the EtherCAT coupler with the remaining cards (as opposed to 2 EtherCAT couplers, with the CPU located elsewhere in the installation). If this is the case, does the pushing/prodding on the CPU cards create the same kind of issues, or is it just the cards in the coupler that have the issue when prodded? Is there anything else in the EtherCAT network or is is just the CPU and EtherCAT coupler? Are the PLC components installed in a cabinet free from dust etc? The photo you showed does look quite clean, but best to ask. Dust never helps  I would suggest that if the CPU cards don't have the problem (and the Coupler cards work find when swapped), then you are looking at an EtherCAT issue. If the CPU cards have the same problem, then I really don't know, but I would be tempted to swap around the PD1000 power cards just in case one of them is faulty. I have no idea if a faulty PD1000 could cause such issues but my understanding is that they do provide the bus that powers the I/O cards. I am just throwing ideas out there at this point. I have never had the exact problem you currently have, but I have had similar errors when I had 2 racks of I/O, 1x EtherCAT coupler and 1x CPU. Faults just randomly appeared a few months after commissioning, and could not be reset without a power cycle, after which it worked fine anywhere from 2 minutes to a couple of days. In the end it turned out to be a faulty EtherCAT junction slave (hub) in my EtherCAT network. This installation has worked fine ever since.
  15. Ahh. Well that might give me some motivation to learn the Visual Basic side of the Omron NA series HMI's, to have a play with that and further my skill set.  I had thought that using a "Set Variable" event for when a button is pressed might work (based on a free running integer from the PLC), but as it turns out, the 'Set Variable' is only a one-shot, based on the quick simulation I did .