Giorgio

Do what gtsuport said but then one more thing while in the Network Type box I don't know if you're going online with an RS-232 d-sub cable, we have a bunch of the CQM1 here, and for some reason (probably WinXP being buggy), the COM port of the project will randomly change so I can't auto-connect. In the "Network Type" box, go to the "Driver" tab, and make sure you have the correct COM port selected that your cable is attached to. If you don't know which COM port is your RS-232, you can find it in Device Manager. I usually right-click "My Computer" > "Manage" ,  and in the WMI panel that pops up, click on Device Manager and expand the "COM & LPT1 Ports" and you should see one of them labeled RS-232, click on it and see which COM port...or just try to each COM port one by one, haha, never had to figure out how to connect without  PLC-> Auto Online  

  I guess I could find an instruction to mask the 1st 8 bits, then compare the last 8 bits of power-down timestamp A512 ddhh (3015 30th of the month in this example) with the last 8 bits of current time timestamp A352 ddhh (0108 if its the 1st of the month at 8AM) and as long as the last 8 bits of A512 are >= A352 we're good timestamping A353 current yymm as power-down time, as long as we haven't been powered down > a month. If the last 8 bits of A512 are < A352 then find some way to subtract 1 day from A353 current yydd, would  " --B A353 D2103" decrement the month by 1? Then "XFER #1 D2103 @D1100" to datalog my decremented-by-1 yymm timestamp to the EM0 pointer memory-location. All that hoop-jumping for a power-down yymm timestamp, and its still gonna be a mess if a machine is down > a month.

OK getting my feet wet with datalogging, have enough understanding to be dangerous, took me forever to figure out the sample datalogging code with the @ symbols in front of memory-locations. Anyways I finally got the datalog and filewrite code logging to the EM0 memory area working after it kept truncating the logged word off my first record, recording the timestamp but not the word of data that changed;  btw for anyone using that sample program needs to change the "MOV #7FFF @D1100" log pointer to "MOV#8000 @D1100" if you're logging to EM0, at least for the CJ1M & CJ2M I haven't tried it on anything else. It seems like EM0 can be treated like an extension of D-memory, so D8000 is an alias for the first word of EM0_00000 Aaaanyways, so we have people shutting machines down so the andon-lights power down, so I gotta log power-up and power-downs. Datalogging the power-on time I'm thinking use the A200.11 first-cycle flag bit to write 0000 0000 0000 0000 or something to the next word in the EM0 log at the pointer, along with the A351 mmss, A352 ddhh , A353 yymm timestamps (in addition to writing it to the "compare for changes" D-Word) OK now datalogging the time of a power-off has got me chasing my tail. Found the "Power OFF Interrupt task", it seems a bit sketchy to try to MOV the 3 timestamp words to EM0 in the 3-5ms you get, is this how the rest of you do it? Does anyone have any sample logic? I'm trying to picture the sequencing. Another option looks safer, "CJ2 Programming Manual" Section 6-6 page 329 shows "Auxiliary Area Flags and Words" A512 and A513 as the "Power Interruption Time" (doesn't say, but I'll assume its A512 = ddhh & A513 =mmss ), so since we still need yymm to timestamp (and  my normal datalogs would be 1 logged word + 3 timestamp words),  I could log it at power-up instead, use the same A200.11 first-cycle flag to first write "0000 0000 0000 1111" or something into the EM0 log at the pointer, then A512 , A513 power-interrupted timestamp flags, then  A353 the current mmyy as the power-down mmyy since OMRON decided not to store a full "Power - interrupt" timestamp. Would this work? I think I'd only have a messed up log if the PLC was powered down more than a month .... dammit no it wouldn't work, machine powers down 15:30:06 9/30/17 so the CJ2 stores the mmss (3006) hhdd (1530) it powers down, next day on 10/1/17 at first cycle its going to log power-interrupt day correctly as the 30th, but the month will be logged as October.  I'd have a faithful 1 bad timestamp a month doing that. Did OMRON only have a power-fail timestamp-flag for the mmss and ddhh to screw with us? Would it have been that hard to log the yymm too? I'd rather not try to log the timestamp using the "Power OFF Interrupt task" in case that just so happens to be the end of the pointer-buffer and the normal "logging" section tries to do a FWRIT from EM0 to the memory card...

Helped with a few Komatsu press installs at the Georgetown Toyota Plant when TMMK replaced them all with servos. I didn't know there was a Toyota Plant in Lawrenceburg, I worked for the HURCO/Chiron dealer out of Lawrenceburg doing cnc installs for a little while. Just started work for one of their Tier 1  stamping suppliers near my house. Kinda funny out of a string of Japanese plants this has been the first Omron shop so far, all the rest were AB, except Hitachi was a mixture, mostly Mitsubishi, & the Georgetown Toyota plant which used a mixture but standardizing on non-US Keyence & their ToyoPUCs Yeah in the Memory window I've done "Upload from PLC", I dont think I've explicitly clicked "Save" or been prompted to save when in the Memory window, I've done "Save As" from the main menu while in the Memory Screen, & I have saved when I got the "do you want to save ___" grey popup box when I try to close the project, and the DM Values are there when I open the project up  so I'm guessing one of those has saved a local copy of DM and EM0 on my laptop. I don't think I ever clicked the "Download to PLC" icon

No memory card, the CJ1 Ethernet/IP card goes to HMI, Remote I/O nodes and the 3 Weldgun motors. HMI used to be able to change D31 TOTAL COUNT, SHIFT COUNT, etc  through the keypad but I took that out (at least I think I did, now I want to double-check, easy for an operator to fat-finger).  I have opened the Memory window and clicked the icon for "Upload from PLC", come to think of it, I think the only times I have had issues with D31 being changed were the times I did open the Memory window and "Upload from PLC", I'm pretty sure I didn't do anything else except Upload.  

 I am less concerned with uploading the DM area from the PLC than I am with not DOWNloading the old saved DM values TO the PLC, so whichever setting prevents downloading DM values to the PLC would be helpful to know.

Thanks, do you know where we tell CXP to upload the DM area? Another user uses CXP on my laptop under their profile, wondering if when they use it they change one of my settings or something.   Whenever I've done a PLC -> Transfer -> Download to PLC , I've always clicked the "Transfer All" box, sometimes D31 is updated with the value I last saved, oftentimes not. In the "Download Options" popup box that comes up I didn't see a specific option for uploading DM Memory Area, or any memory area for that matter, so I'm guessing its somewhere else  

Starting to find my way around Cx-One, running a CJ2M-CPU33, logic runs a rotary indexing-table destacker weldcell.  I am trying to figure out a way to prevent changing the value stored in UDINT TOTAL_PART_COUNT D31 when I upload a revision. The D31 increment line is section Main_Operation:40 It is a cumulative count of all parts run to date, so there is no conceivable reason I am ever going to want the TOTAL COUNT saved in an old revision to overwrite the current value.   The cell runs all day every day, so for a revision I'll open the last *.cxp file, connect to PLC, compare PC to PLC, if same I'll "Save", disconnect, make changes, save .cxp as new Rev#, and upload. When I upload a new revision, I usually (but it seems not always)  overwrite the value stored in UDINT TOTAL_PART_COUNT D31 on the PLC (which of course is bigger than whats in the newer revision since the machine has been running). Usually I remember to write down the TOTAL_PART_COUNT in the PLC before I upload and just manually change it after uploading the new Rev, but when I forget to and realize a week later, I get to have a lot of fun reading paper production logs. Is there a way to protect certain memory-areas like TOTAL_COUNT from being over-written by a Revision upload? Maybe I need to use a different memory area or instruction set? Next revision is going to be adding data-logging of faults, I'd like to create 2 arrays per fault, one for fault timestamp and one for # of minutes before the fault was cleared, and I'd certainly wouldn't want those arrays over-written with older values when I upload future revisions. Are the EM Memory Area values implicitly protected from overwrite? PS. The 13.15 "Trash Bit" contact everywhere  is from the integrator, not me, I have at least figured out the P_Off flag AS-260 IL100 LASER PARTSTCK REV23 2.27.17.cxp

Thanks IO_Rack, FLTL was exactly the conversion instruction I needed, I assumed the CXP MOV instruction worked the same as MOV in Logix500/5000, converts Source data-type to Destination data-type, so the CXP MOV instruction is the Logix equivalent of the CPY instruction (for anyone else coming from Logix).

Very new to CX-Programmer, I had a question, hopefully someone here has done something similar and there's some easy copy-paste sample code.   Programming a CJ2M-CPU32 using CX-Programmer V9.4 with an NS8 HMI on CX-Designer V3.411 I want to calculate a REAL Operator_Efficiency value from PARTS_COUNT / SHIFT_GOAL_COUNT in the PLC, and display it on the HMI AUTO_CYCLE screen.  PARTS_COUNT & SHIFT_GOAL_COUNT are both DINT,  I tried using the /F (457) Floating Point Divide to calculate a value to REAL Operator_Efficiency , and it calculates properly as long as both PARTS_COUNT & SHIFT_GOAL_COUNT are >0, when the Operator first starts PARTS_COUNT & SHIFT_GOAL_COUNT are of course both 0 ... ... then using *F(456) Floating Point Multiply for Operator_Efficiency X 100.  I feel like I'm reinventing the wheel here, I like to have all my logic in the PLC and the HMI just basically be momentary push-buttons and numeric displays with no HMI MACROs/logic to confuse the Industrial Maintenance guys.  Any help would be nice, modifiable sample code even better,  right now my best guess is try to use a macro in Designer on the NUMERIC_DISPLAY showing Operator_Efficiency to display something meaningful at the beginning when either PARTS_COUNT & SHIFT_GOAL_COUNT are 0.  Including a copy of what I've done so far, its the PARTS_COUNT section   AS259-12.bak

Just 21300 or the whole address?

Hi, I'm new to this forum and the CX platform, just reading through old responses, I would like to look at the file posted by Michael Walsh     StringTesting.zip is not a live link on my browser does anyone know how I can get to it?  Is there a live link to the file on the bottom of the comment or on the bottom of the post, or are links on MrPLC only live for the OP or something? Thanks in advance