tworst

I am absolutely obsessed with making clear, consistent, and logical tag names.  Most people don't give it a seconds thought and come up with the first thing that pops in their head and to the point where the tag names become more of a point of confusion rather than helping you understand the code.  I have one line where the offsite programmer just called all the digital inputs on a card switch 1, switch 2, etc.  I just want to scream when I see this.  Anyway, I much prefer using tag names over memory locations as long as sufficient effort is put into the tag names to make them useful. Marketing.  All they do most of the time is confuse everybody.

Any new NJ series would be used in a new installation.  I have seen a few comments about the undesirability of tag based programming.  I kind of like the idea of using tags instead of memory locations.  What is the disadvantage of using tags over memory locations?

I did notice that the NJ is classified as an automation controller while the CJ is classified as a PLC, not sure what the difference is. We do use a combination of CJ and CP PLC's, but I was thinking in the case where we are going to use a CJ anyway to upgrade it to an NJ.  Usually, a CJ is the main controller on a line and CP's are then used for low cost I/O.  

At my company, we are bringing in some new lines and have the chance now to RFQ the PLC's.  Our current standard is CJ and CP series PLC's and I am wondering if going to the new NJ series would be worth it.  I don't know what all the advantages or cost differences may be at this point, although it does appear the NJ uses an IDE called SYSMAC, which is a selling point to me already.  I was hoping some members on this forum might have some input on their satisfaction from moving to the newer NJ series PLCs and the advantages it brings.  The bean counters where I work are pretty stingy, so any significant off the shelf cost of the NJ, along with any cost differential due to software, displays, I/O, etc would need concrete justification.  I am looking through the Omron website to learn more about NJ, but there is nothing like other people's experience with a new vs old product to get more confidence in making a decision.

Example worked.  Thanks.

I am using function blocks for the first time.  I have pasted one down in my code from the library.  I can't figure out how to connect the outputs of the function block to actual memory locations.

OK, making progress.  First tried using STR type functions but those operate on HEX digits, not a numeric value like 65535.  Couldn't find a way to convert 65535 to HEX digits first and then use STR.  So then tried the float conversion.  Had to make a symbol of type DWORD and store 65535 in it first using FLTL.  Then used the FLTS on this value, with proper control words, to convert it to ascii characters and that works.  I did notice I got a warning during the compile as it didn't like data type of DWORD used as an operand in the FLTL instruction so changed it to DINT and warning went away.   Also, since my value will always be an integer, I think I can drop the +0.5 that accounted for rounding. Thanks for all the help.  Doing this simple task in OMRON is like one step removed from programming in machine language I did 30 years ago.  But I am kind of new to OMRON so I guess I will have to learn.

OK, this is getting maddening.  Just want to convert 60,000 decimal to "60,000" text.  I have spent hours now.  How hard can this be?  I am pretty new to OMRON, mostly program in AB, so I am learning how OMRON does things and have a reasonable handle on it.  But this is getting ridiculous.  I tried the FLT function but only works up to 32,766 and then goes negative.  Somebody mentioned using ST but how?  Has anybody actually converted 60000 to "60000"?  Can you provide specific programming in ST and/or LL?  Sorry about my frustration but I could do this faster with relays and and LCD display.......................................

OK, got my date/time figured out. But now I also want to write a 16 bit numeric value, 0-65535, as a string to the text file as well.  ASC only lets you pick out up to the 4th character.  Not sure if there is another function that lets you do larger numbers.  I have been playing around with ASC, BCD, STR, etc, but still can't find a way to do it.  All I want to do is write a 16 bit numeric value as a string to a text file.  The value is in D354.  Suppose it is 45322.  Just write it as "45322" to the text file.  I have been using a combination of LL and ST to do this with smaller numbers like 12 with common functions like ACS, but after 4 digits, nothing works.

I am already writing string data (symbols) values to a text file on the memory card of a CJ2M.  I just want to add the PLC date and time to each text record.  The PLC date time is in the area of A351 and I can see the year, month, day , hours, min, sec in the memory viewer when BCD is selected as the interpretation.  So, 32 sec is 0011 0010.  I want to move this into a symbol I have defined as a string so the bits need to be the ascii codes for "3" and "2".  Then I just want to write this string to the text file which is no problem.  But I can't figure out how to convert the bits in the A35X words to their ascii string equivalent bits.  Anybody done this?