Andy_P

MrPLC Member
  • Content count

    336
  • Joined

  • Last visited

Posts posted by Andy_P


  1. I am using CX-Programmer V7.2, and I needed to install the Omron USB driver the first time I connected to a CP1L. Using WinXP, the standard prompt of "New hardware found" appeared when I connected it for the first time, then just went through the wizard prompts to install the driver. Andy.

  2. I don't think that this is possible in the normal ladder environment. Maybe you could use index and data registers to do what you want? i.e. IR and DR Andy.

  3. I cannot reproduce this error, it works as expected for me. I would have to agree with beegee that the most likely explanation is that D121 is being referenced elsewhere and changing the value. Is it possible that D121 is being indirectly referenced? One test I can think of trying is to @MOV the value of D121 to a definitely unused address immediately after the @MOVD instruction. That way you can see exactly what MOVD is producing with the knowledge that nothing else can alter it. If this new address contains #9550, then there is no bug and something else is altering the value of D121. If it contains #9650 then there is indeed a bug. Hope that helps. Andy.

  4. I think I am right in saying that a DDM file is nothing more than a data dump file containing Data Memory values, and is created using the Syswin programming software. In other words, it is not a program at all. CX-Programmer can import these files and then save it as a .mem file. If you have a project created for your program, then go to the @Memory' editor and you can import the file from there. However, if you were expecting to be sent an actual program, then I am not sure how much help this will be to you, unless it contains translated text strings perhaps. Have you been sent a .swp file? This is a program file created by Syswin, and can also be converted by CX-Programmer. Hope that helps. Andy.

  5. What value are you pre-loading DM100 with? Make sure it is a valid BCD value, or I don't think the instruction will work. i.e. if you want a value of two hundred, make DM100 equal to #0200, and not #00C8. Hope that helps! Andy.

  6. I would have to agree with the other posts and say that the CPU23 route would be the preferable option. Even if you managed to squeeze your program down to fit into the CPU22, there will ALWAYS come a time (in my experience) when something needs to be added / modified and hence push you over the limit again. Having a CPU that tight for space is not a good idea, in my opinion. Andy.

  7. A customer of ours wanted to order a machine, that started up and performed some operations the moment the power was turned on. Without any operator interference at all, no start button press, nothing! I should say that the machine is nothing as large or scary as a saw-mill, but even so. My boss (not technically savvy about safety at all) was inclined to agree to this. I had to say I was not prepared to do it and would take no responsibility. It's a small company so there is a tendency to agree to whatever request a customer makes, however ridiculous, and in this case potentially dangerous. Happy to say that sense prevailed, and startup of the machine has to be operator initiated. The mind boggles. Andy.

  8. Not too sure how to do what you ask, but one method I have used in the past when I was using Siemens is to have a step value word, for example D0. Set this to a value of &10 (for example) initially and then compare it in a 'Step 10' rung. If the value equals &10 , then step 10 is active and you can perform actions, i.e. energise solenoids etc. Also using this comparison, have a 'Transition 10' rung. When it is active, and the conditions are met to go to the next step, simply move the next step value you wish to run into the step word. eg &20. It is then easy to add intermediate steps, or indeed make the sequence run whatever step you like. Just move the step words' value you wish to run next at the completion of each transition. I hope that makes some sort of sense! Andy.

  9. Hmmm, well just tried this in a FB: FOR MyInt := 0 TO 31 DO MyBool[MyInt] := TRUE; END_FOR; I set both MyBool and MyInt to be internal and also MyBool to be 'AT' data memory D0. When the code is run, all 32 bits of D0 and D1 are turned on, so it appears to work for me. Is that what you meant? Andy.

  10. Best of luck with that job. No doubt you will be given a wish list compiled over the past 35-40 years of things people would like the m/c to do, but previously not possible / cost effective to do! I have had a hand in a few 'upgrade' jobs such as this. While there will undoutedly be a few headaches along the way, when it all finally falls into place the job satisfaction factor is pretty high. Andy.

  11. Well now, that is strange, and not immediately obvious (to me) why the second run would not work. But indeed it does not, as I tried it in simulation. An alternative to your solution of the first rung, is to place the WARNG contact after the initial conditions and UP instructions. Andy.

  12. I have had the same problem on a CPM2A, and it turned out to be the internal power supply intermittantly failing on power-up and causing a 'Power Supply interruption' fault, which was recorded in the error log. (Have you checked the error log?) Unfortunately in this case, the solution was to replace the PLC for a new one. Andy.

  13. I would agree with that mostly, but it does seem that when using FB's on a CP1L, there is quite a significant hit taken when actually calling them, especially if there are several inputs/outputs to the block. The spec given (in manual W451-E1-03 page 1088) states that when calling an FB, the startup time on a CP1L is 320 microseconds, and each boolean operand is a further 60 microseconds, all before the contents of the block are even executed. Several FB's in a program can soon add to the cycle time significantly. Andy.

  14. Had word from tech support here in UK that this is indeed a firmware bug in V1.0 of the CP1L PLC, and the instructions do not operate. Apparently these issues will be fixed with soon to be released PLC's with firmware V1.02. Andy.

  15. I have a problem using the UP(521) and DOWN(522) instructions on a CP1L. They do not appear to work! Using a simple test program, with only one line as follows: LD P_1s UP(521) OUT W0.00 ++(590) D0 W0.00 never triggers, and D0 never changes value. However it works as you would expect when running the program with the simulator. The same problem exists with the DOWN(522) instruction. DIFU, DIFD, and differentiated contacts all work as expected. I am using: CP1L V1.0 PLC CX-Programmer V7.2C CX-Server 3.1 Has anybody encountered this problem, or can reproduce it? Thanks, Andy.