MrPLC Member
  • Content count

  • Joined

  • Last visited

Community Reputation

1 Neutral

About Sunbic

  • Rank

Profile Information

  • Country Spain
  1. They also say the whole program is executed in parallel. It's clearly not true but it's enough explanation for most users. But what if the PLC is actually managing CPU threads? How does one know if there's nothing to either deny or confirm the way the PLC handles the program execution? If it does not use multithreading and it's just a whole single I/O operation thread, it is completely sequential and each step is executed after and only after a former one finishes. Writing an instruction under another should be enough since both can't be executed at the same time. Turns out I should not be doing that.. so either the CPU handles instructions faster than the memory updates or that statement is false. It is more complex than classroom material.
  2. That's exactly what I needed to hear, Michael, thanks. I did not know about using different rungs. Is this something you have learned over the years or is there an official paper on this? I have read some docens of Omron manuals and I have never come across this.
  3. If you manage data you end up manipulating it, moving it here and there, splitting and stitching, and due to the nature of ladder I wonder how high is the probability of race conditions happening. I have yet to see an in depth explanation of this, of how the processor handles threads and what gets the biggest priority. I have never felt confident modifying the same data twice when both instructions are executed by the same trigger. You can always use SFC - not an option where I work though - or make a timer after each execution, but that's just a nasty way to do it, and gets extremely bloated really quickly, more if you are using differentials. Is there a real way to make the PLC execute A THEN B in ladder without using these? I have wondered this for years. By the way, what is the use of P_Step?
  4. Cycle Timer

    I don't really like this since you don't have much precision, and you will be missing the time elapsed between 3.00 and P_0_1s, but still
  5. CP1E TXD RXD RS485 Send/Rcv Hex Values?

    I suggest you start a new program only targetting the data transmission, and hardcode a command and each instruction value and see first if the port is actually transmitting data, and if so if your device is interpreting it. The problem may or may not lie in your code, it's impossible to know without the hardware to test it.
  6. Note it does work; when you set on a retentive bit it stays unmodified (unlike the former P_On). The problem goes beyond the starting flag though. It looks like I just can't use timers here.
  7. CP1E TXD RXD RS485 Send/Rcv Hex Values?

    Hex, decimal and ASCII are just ways to show the same data.. they represent the same bytes in different ways. You can change the way you see memory channels in CX Programmer (hex, decimal) in the view tab. You will just be changing THE WAY you see the data, not the actual data. UINT, INT, LONG or BOOL are the actual data. They are objects that occupy memory (bytes). Take a look at this Note that UINT holds two bytes, as most data you will operate in your PLC. To use UINTs, open up a D channel and write some number there or write a MOV instruction targetting a D channel, and there you have it (D channels are two byte). To make a string you have to write data in consecutive channels. So if your device requires the following command: Hello world! Which occupies 12 bytes, in your PLC you will have to write six consecutive channels D100 = #4865 //#48 H #65 e D101 = #6C6C //#6C l #6c l D102 = #6F20 //#6F o #20 space D103 = #776F //#77 w #6F o D104 = #726C //#72 r #6F l D105 = #6421 //#64 d #21 ! If you give the PLC all those channels to send over the port you will be sending 12 bytes, and the device will receive 12 bytes. If that's what it wants it will work. I suggest you write data in hex format since in hex you can see the pairs of bytes (like the example), unlike decimal, which shows the sum of both bytes.
  8. For the record, none method works. I replaced the W bit with an H bit, it worked as expected, but nothing else does. Every instruction gets reset when switching to PROGRAM mode, no matter the flag that is executing them. The H didn't flicker and those timers jumped from 0 to their original values back and forth switching. And since the processing mode overrides the flag, moving the code to a separate task does not work either.
  9. Yes, this is it. I had the same idea yesterday - albeit using a DWORD channel, but I didn't like the idea of starting the program with a comparation. Thanks also for taking the time to make the pictures. I'm going to try whenever I can and I'll update with the result. I'll also try your other option, that's an interesting feature that I've never used.
  10. Hey, this is driving me nuts. I have set up a TCP/IP chain communication between a CJ2 and multiple devices. I figured I could use the P_On to reset these communications and all of its data. In essence, it all has to be reset when the PLC does the power off/power on maneuver. It works well.. except that when I switch to monitor mode the P_On blinks. Switching from program mode to monitor and viceversa causes the program to lose the P_On signal, so everything keeps resetting whenever someone connects to the PLC, and it's not like there's a hundred signals to choose from - as far as I know this is the only one I could use. That's the way it has to work, but it needs to be something that becomes active when the PLC boots up and essentially remains unaltered as long as the PLC is on.