MrPLC Member
  • Content count

  • Joined

  • Last visited

Community Reputation

1 Neutral

About strantor_

  • Rank

Profile Information

  • Country United States
  1. Alarm history in NB Designer

    Yes I agree. I devoted a lot of time in the manufacturing plant where I cut my teeth, pondering to what extent cultural differences affect our logic and what we find intuitive. Most of the machines in that plant were from the '60s, and were a mixture of German, Austrian, American, and French machines. As a noob I picked up ladder diagrams very easily with no real training, but the old European physical relay logic prints were something that took me a while to grasp. I kept telling myself "think like a German." Siemens is another example. Maybe for a German it's totally intuitive. For me, the time I would have to invest into learning where they've hidden everything probably wouldn't pay off, unless I was to groom myself into a "Siemens Specialist" and do only Siemens for a living, so I stay away. I think my American upbringing naturally led me to find Allen Bradley and Ladder Logic more intuitive than Siemens and IEC drawings - in some way that I don't fully understand. I can't put my finger on it, but there's definitely something to this. 
  2. Alarm history in NB Designer

    Excellent! You saved the day again, Michael! Thank you! I thought I had tried everything. "Event?" = [Alarm History] Really? That's wasn't even on my list of things to try. I'm starting think maybe I should have attended some vendor training before diving into NB. Other Omron stuff was more intuitive.  
  3. I would like to have an "Alarm History" page showing historical alarms with timestamps for time generated/acknowledged/cleared. Like this (ex from web, not my work):  This is a fairly common feature but I do not see an out-of-the-box solution in NB designer. I have played around with the "Event History," "Alarm Display," and "Event Display" and none seem to fit. I feel like I'm supposed to make "Event History" work for my purposes, but it's pretty confusing for me. The manual could be better. Any example of, or guidance for implementing an alarm history in NB,  even if not exactly like I want, will be greatly appreciated! Thank you!
  4. omron CP1E-E30

    Ah ok. Thanks for the explanation. I accidentally deleted my question while you were answering it. I was trying to edit it to show the quote.
  6. Ok I wasn't able to add the CP Series and transfer directly from CJ to CP. For your (and everyone's) reference, here's how I had to do it, using the general concept that you provided. Starting point. CJ/CS/NJ with all my addresses in it Step 1: add a CP series (or any PLC with serial port I guess). This is just an intermediate container for information. Add a serial link between them Step 2: Perform the memory address transfer as described in the document provided by Michael Walsh in post #3 Step 3: Delete the CS/CJ/NJ, and accept the scary confirmation message.  Add a CP series where it used to be. Configure the IP address according to the document Step 4: Double click the HMI , Go into the communication settings, note that the HMI protocol is different than the only PLC in the program. Change it to CP series ethernet. Step 5: Perform the Same find/replace operation to migrate the addresses out of the temporary CP1H (PLC1 in my case) to the new CS/CJ/NJ (PLC0 in my case) Step 6: delete the temporary CP1H and serial connector Done!   Thanks Michael!    
  7. Thank you Michael. Following those instructions it worked perfectly just now, when I migrated the addresses from CJ/CS/NJ series to another CJ/CS/NJ series (as a test). But when I add the "CP Series Ethernet" it does not work. Starting from scratch with an untouched copy of my program, I add the CP Series Ethernet, set up IP address and everything as described, and go to find/replace, on both sides of the window, the new PLC is not in the list. Only PLC 0.  Just to make sure I wasn't crazy, I added 3 of each. It will only let me transfer between CJ/CS/NJ series.       EDIT: figured out that if I change the the comms protocol in the HMI from CS/CJ/NJ to CP series, now my options become PLC 0,2,4 instead of 1,3,5. So it would appear that to use find/replace there is an unreasonable prerequisite that all the PLCs be on the same protocol. I will try adding a serial connection instead of an ethernet connection, see if that works, and report back.   Thanks again for providing the document.
  8. P.S. In the event someone says "just use the "Change PLC Model" option by right-clicking the PLC" as such: I tried that. When I do that, there is what I think is a "bug" that afterwards there is no PLC (PLC0, PLC1, etc) listed when I go to assign an address to something in the HMI design.  
  9. I apologize in advance if I am unclear as to what I'm trying to do. I've retyped this several times and it seems to be one of those things that's hard to communicate if you're not there to see it - Like Christopher Walken trying to explain Baseball in Blast From The Past. I'm writing programs for an NB10 and a CJ2M-CPU32 with Ethernet comms between them. I am waiting on delivery of the CJ2M-CPU32 which is taking forever, and in the mean time I've been using a CJ2M-CPU12 that I have laying around - it doesn't have an Ethernet port. I've already programmed a significant portion of both HMI and PLC, without the benefit of having them communcating with each other. Now I'm getting to the point I really need them talking and getting desperate without my CPU32, and trying to make something else work.  The only Omron PLC with an Ethernet port that I currently have is a CP1H with a CP1W-CIF41 option board. All addressing in the HMI I have mapped to points in the (future) CJ2M-CPU32. I tried using my CP1H as a "simulated" CJ2M with the same IP address, but the HMI is having none of that. It's giving me a "[1] PLC Response Error," which is different than the "[2] PLC No Response: 00-0C-3" that I get when the cable is unlugged or when the PLC IP address is wrong, which tells me that it is "seeing" the PLC at the correct IP address but it too smart to be fooled by a CP1H when its looking for a CJ2M. When I put a dummy program (NB/CP1H) in the NB and in the CP1H, it works; I can toggle a bit from the HMI in the PLC. But when it's looking for a CJ2M, apparently only a CJ2M will do. In the NB program that I've already invested so much time in, I can't simply change the model of PLC. If you start with CJ series, that's it. If you want to change models, you have to delete the CJ series, and put in a new CP series. But when you delete the CP series, it deletes all of the addressing for every single widget on every screen, that was mapped to the original CJ series.   I hope I have clearly stated my problem. Are there any suggestions for either tricking the HMI into thinking a CP1H is a CJ2M, or migrating the NB project to a CP1H without losing all addressing, or something else? Thanks in advance, Strantor.
  10. Why TXD(236) doesn't work, but RXD(235) works

    I'm chopped liver.
  11. CP1H does not support STRING data type in ST?

    Thank you. I did come across that later, but I still feel somewhat justified in being irritated with Omron on this matter. That little blurb that you circled is only half-way informative. It is the only mention anywhere in any of the manuals, and it doesn't come close to saying "CP series cannot support ST instructions for String type." I understand that the ST function came after the release of CP1H, but can Omron not create a manual revision covering CP1H ST instructions? And if they're not into revising manuals, how am I to know that the circled blurb is even current? Maybe the manual came out before CP1H? I don't know the timelines of these things. This should be spelled out in bold, in a logical place that someone would look for it if they were considering purchasing it for their application. Like in the datasheet released may of this year, page 1, Features, 8th bullet down,  where it says " • The structured text (ST) language. Makes math operations even easier ."  Maybe instead it could say " • The structured text (ST) language - Partial Support. Makes math-only operations even easier. (See W451 Rev 2017 section 5 - Structured Text)" - and then actually release a new W451 with a section on structured text.   Anyway, rant over. Thank you for your response and I'm sorry if my reply seemed negative. I'm still a little butthurt. I'm moving on though. The CP1H is in pieces in the bottom drawer of my cabinet, and I have a CJ2M on the desk now. This one DOES support string. All good now (except the money).
  12. CP1H does not support STRING data type in ST?

    From W451: NO MENTION of fb restriction on string functions
  13. CP1H does not support STRING data type in ST?

      I appreciate it but, no, it's not having any of that either. It won't let me define a string variable in ST. And if I try to get away without defining a variable (put conversion directly into TXD) it tells me "instruction not available for current PLC"   How frustrating! I didn't see this restriction printed in any documentation before I selected CP1H for this application, and I still don't. I have looked hard through all my manuals twice and I don't see this printed. In CP1L/H Programming manual W451, CX-Programmer manual W447, CP1H operation manual W450, it is never mentioned that I can find! It really lead me to believe it as capable. Omron is trying to make me feel stupid, successfully. Next time I buy a new car I will have to verify that it has gear oil in the differential. Because every car on the lot will have shipped with diff oil except the one that I select, and the owner's manual won't tell me that on this very specific model the owner is expected to put it in.
  14. CP1H does not support STRING data type in ST?

    I just tried to do the same thing in a ladder FB. String variable, it gave me the same error. But then in the FB I changed the variable type to WORD and it worked. "neat" little workaround in ladder FB, but too bad it doesn't work in ST. in ST I get this error: