strantor_

I installed NB designer 1.45 on a new Windows 10 computer and none of my NB projects will compile. I get this error: I downloaded & installed the latest NB Designer (1.46) and tried again, same result. I AM running the software as administrator, and also tried running in compatibility mode for Windows 7. Any Ideas? Thanks in advance  

I currently have multiple brands and suites of PLC software on one laptop and they don't play nice with each other. I have everything but Sysmac Studio on there; haven't installed it yet. I just got a new laptop with a good processor and 64gb of ram, running VMWare. I'm going to segregate my PLC softwares into different VMs by brand, or by suite if necessary. So is it a good idea to install Sysmac Studio in the same VM with CX-one? Or should I give it its own VM? And while we're on the topic, are there any other Omron softwares that might conflict with other Omron software?

Excellent! Thank you.

I don't know what the problem actually was but I created a Windows 7 Virtual Machine and installed NB Designer there, and it works fine. Supposedly compatible with Windows 10, not sure what the problem could have been

The circled portion is not inside any IF statement, so as soon as you go to state 30, it immediately goes to state 40. And per the symptoms you've described, it seems from state 40 it also goes straight to state 50, which sets it back to state 10. And all this happens way too fast for you to see.

I hope the HBM load cell does not use very deep ASCII commands. I just finished an ASCII project with a different device, and it was originally specified for CP1H, which does not support STRING data type (neither does CP1L/E). Here's an example of the message exchanges required to get a measurement value from the device: Because of this, especially that long string "D/KS....." which needed to be examined and values parsed out, the project quickly became very complicated and difficult without STRING data type. I had to change the PLC spec to CJ2M in order to meet the deadline.  If your load cell is just sending you a number it should be easy enough, but if requires a whole conversation to coerce a value out, or it's sending something like above, consider doing something else.

Work bits are non-retentive memory. Use them for almost everything, except that which needs to be retained. D20.00, if ON before power-off, will be ON when power comes back. W20.00 if ON before power-off, will not come back to the ON state when power comes back.

You bet!

I found A solution. Not sure if it's the best solution. Open to new ideas. I just changed the WORD in my datatype to a BOOL and new the BOOL is named. When I type the WORD address into the TIMLX instruction it inherits the symbol name from the datatype but shows no ".xxx" - good enough for me.

I am getting ready to migrate a bunch of TIMX to TIMLX. For this I want to create a custom data type for the new timers' parameters. I want to give a name to a BOOL within a WORD that is also named. Because for some reason TIML/TIMLX makes you specify an entire word for the completion flag, when all you need is one bit of the word. Maybe it will be more clear if I demonstrate:         Is there a way that  I can name the bits within my CompletionWord?    Thank you  

I've uploaded one of my projects that contains the whole shebang of networking with the DRM21. CX-Integrator file and CX-Programmer file (all logic & FBs deleted - CIO tags still intact) . You set up your remote I/O memory locations in CX-Integrator and then add CIO addresses in your CX-Programmer program that correspond to what you  put in CX-Integrator.       DRM21 example.zip

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.

Here's an anomaly for ya! (I finally got a break ) I received the CJ2M today and hooked up. I was in the middle of performing my multi-stage process when I looked over and saw that the HMI was just talking to the CJ2M right out of the box. Amazing! It's looking for a CP series, instead found a CJ series, and for whatever reason, it's totally cool with that.

I just received a box of Omron parts from my supplier and they had dust/lint on them. That caught my eye so I looked harder and realized there are no stickers over the vents that I'm used to seeing. The ones to keep debris out during installation and say "remove after installation."  These were purchased as NEW parts and they were inside their proper boxes sealed with Omron tamper tape intact. The boxes do not look like they have been opened. The PLC and I/O cards have MFG dates <6mos old.  I am used to Omron components coming with the debris sticker, and had they not been covered in dust I probably wouldn't have missed them. I don't know what to think. Now I doubt my memory of the stickers; I know for a fact I've seen them on Omron PLCs and I/O cards, but on ALL of them? I'm just not sure. And now I can't remember when was the last time i specifically opened CJ1W I/O. So I Google Image searched my specific cards and found several images of them with the stickers. I know that, at some point, these stickers would have been on my cards. Has Omron ceased the practice of installing these stickers? Or did I buy not-so-cleverly disguised used cards?

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. 

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!

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.  

https://www.youtube.com/watch?v=Pm0csoze7e4

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.

You bet!  

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!    

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.

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.  

I'm chopped liver.

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).