Please Help-Another Turret controlled by PLC

[drbitboy]

I will implement those now. I was having a few issues last night, the CCW was going high before CW. I solved that issue though. I will try it as soon as i get this uploaded to the PLC.

I'm also having trouble controlling X8 with modbus as well as reading y005 when there is a fault. Is it possible to read and write to coils without having physical wires present? or do i need to run those wires to the correct pins?

I don't think you should be able to write to X008 with Modbus, because it is a discrete input; you should only be able to read it. Are you using Modbus to trigger something, or are you trying to overwrite a value into the discrete input?

I need a start tool change signal-Tool change finished(which is X008).

I don't think this is right. X008 is an input, so (1) it can't be an output to indicate [Tool change finished], and (2) it cannot be written to via Modbus. Yes, you could move some of these items internally to Cx bits, especially if you want to stop the turret on stall OR e-stop events. A stall event is detected by the code i.e. when the stall timer (T3 TOF) expires (T3 has a falling edge) and the brake is released. An e-stop event would be a discrete input i.e. operator hits an e-stop button. If you are trying to use Modbus to simulate/override these signals because there are wires to inputs yet, then you will need an input buffer section to combine (probably OR) the inputs with Modbus-controlled bits (again, Modbus cannot write to inputs), and then use the ORed results where you are using the inputs now.

Actually, I am not sure what your X008 is supposed to do; it looks like all it does is start the stall timer, so I assume you send it when the Modbus master sends a new target. But you could just as easily use a rising edge of [Motor CW] to start the stall timer i.e. when a new target position is received that is not equal to the current position, then the motor will start turning the turret clockwise, and that indicates the start of the move sequence, so you could use that rising edge of Motor CW to start the stall timer.

Y005 is a read/write discrete output i.e. coil, so I would think you can read it using Modbus Function Code 1.

 

[Aaron_]

I see what your saying now. Yes initially I was using X008 to start the Tool Change program. Now were using C2 to trigger it to start. Problem now is, C2 I guess is triggering to fast and the CW motion isn't starting. Its updating the value for DS1 but not triggering the Cw motion to start.

So the only thing im trying to prevent by giving the program an actual start signal is when i power up the machine if the machine thinks there is a different tool in the turret than there is it will write a different value to DS1. We had it before if DS1/=DS2 that would start the program.
Or if there was an e stop condition then as soon as the e stop was released it would continue the program if there wasn't a start signal. I could be wrong here as i haven't made it this far yet.

So at the end of this, I just want to prevent the turret from starting just because it sees that DS1/=DS2.

I can send an E-stop condition to the PLC to stop. I can send a signal back to the control if there is a fault during the tool change and be able to reset it.

Then a tool change completed successfully sent back to the control via modbus.

You have been a life saver during this whole process. I really cannot thank you enough.

 

[Aaron_]

I'm also trying to keep this project from getting to complex lol. So if connecting the PLC's power to a relay on the controller so it turns the PLC on/off when an E-stop condition is true, I can do that easily.
I can also only energize the PLC if the machine is in the enabled state. That will cut back a little bit of code within the PLC if that would be the more simple solution.

 

[drbitboy]

Now were using C2 to trigger it to start. Problem now is, C2 I guess is triggering to fast and the CW motion isn't starting. Its updating the value for DS1 but not triggering the Cw motion to start.

I don't think that is what is happening. See the Click Programming help file; images below. We need to fiddle with the Recv instruction logic, probably put a [NC C2 NC C3] pair ANDed on its input rung to ensure it is re-triggered to receive data.

 

[drbitboy]

I'm also trying to keep this project from getting to complex lol.

Yah, lol is right. That ship sailed a few days ago.

 

[drbitboy]

Yah, lol is right. That ship sailed a few days ago.

And this is not meant to sound bitter, because that is not the case at all and I enjoy these kinds of problems, but what is making this complex is the goalposts moving around. We are sixty-odd posts in, and the concept of an E-Stop was not introduced until Post #45.

Somewhere on this forum there are posts about how to approach a problem. The first thing is understanding the process, which includes listing all of the inputs and outputs and how the process is supposed to behave in all possible scenarios to all possible combinations of those inputs.

Interacting with the turret is one thing, a nice small piece of the process, and I think that has been solved for some time. But now we are adding bells and whistles about e-stops and modbus commands and power cycles (intentional or not). So, what is everything that you want this thing to do? Write it down; it should be no more than a page, maybe two. That is what will determine how complex the project will be.

 

[drbitboy]

@Aaron_: check pm

 

[I_Automation]

I can also only energize the PLC if the machine is in the enabled state. That will cut back a little bit of code within the PLC if that would be the more simple solution.

If you are talking about providing power to the PLC outputs common then this is a good idea.


I, and others, literally hate when the PLC is powered down unless the MCR/K1 is on. I have been online when the E-stop was pressed and had editing problems. I just don't think it is good panel design to power down the PLC unless the main disconnect is off. I have even seen this when the PLC was monitoring the MCR/K1 relay being on in the code, but if it wasn't on the PLC wouldn't be running so all that code was a waste - until I rewired the PLC power.

 

[Aaron_]

If you are talking about providing power to the PLC outputs common then this is a good idea.

I hadn't thought about this approach. Cutting power to the outputs, stopping the motors from turning is all that would be needed. Thank you

 

[Aaron_]

drBitboy is right. I did know from the start that after the PLC was controlling the turret.
That I would add on the modbus communication. I was following another thread where they did something similar with their turret. They said to get the turret running under PLC's control then add in the modbus communication like it was no big deal. While that sounded simple at the time, I now know better.

The E-stop was an after thought. So had I planned a little better this little project would be done. I apologize for the lack of planning on my end. I do however greatly appreciate you guys that get on here and help out beginners like me.

 

[Aaron_]

Alright I implemented I_Automation suggestion of connecting the outputs power from the PLC to a relay controlled by the E-Stop. The plc with stop turning and after 4sec output a fault to the control. Everything seems to be working now after drbitboy got a few more things sorted out for me.

Here is the working code up to this point. When I finally call this project done I will post the lua code for mach4. So hopefully it helps someone in the future.

 

[drbitboy]

Nice!

I still want to see those comments; that may seem like a low-ROI activity right now, but it will pay huge dividends in a couple months when the system is not readily accessible to memory. You might be able to copy most of the comments from my turret003.ckp, but make sure you understand them; if they are not clear, ask.

Also, it's too late now but for for future reference, @James Mcquade often posts a checklist of how to approach a task like this from the beginning. The latest instance I could find is at this link.

TL;DR:

I am still not convinced we need C10

1. C2 should not have its rising edge until DS1 is updated from Modbus, so the rising edge of C2 could be used to start the initial CW motion instead of C10. That also means the lua code does not need to send the "start" bit to the PLC and C10 bit via Modbus, which eliminates that communication as a possible point of failure and/or difficult-to-debug cause of problems.
2. It is not likely,but certainly possible, that the C10 rising edge via the Receive instruction on Rung 4 could occur before the new target position is read via the Receive instruction on Rung 2.

If you do decide to stay with C10, we should change the lua logic to use the "set-and-forget" design pattern i.e. the lua code only ever writes (sets) a 1 to the value of C10 via Modbus, and then does not write a 0 one second later i.e. lua forgets about C10 after writing a 1, and relies on the PLC to change the value of C10 back to 0.

For that to work, when the PLC detects to a value of 1 in C1-, it (the PLC) should Reset the value of C10 to 0. The way to do that might be a new rung

    C10       C10

----] [------(RST)---

​

after the rung that controls the output [Motor CW].

The motivation for the set-and-forget approach is a general distrust of comms: if you browse this forum you will see that a significant fraction of the threads boil down "comms don't work or stopped working."

It is bad enough that we have to rely on the Modbus comms writing a 1; we want to avoid, if possible, doubling the number of possible points of failure, and we can avoid that by not relying on the [lua code + Modbus + TCP/IP LAN + Ethernet] to also write the 0, necessary for the next 1 to be detected, as well; the rung above will do a far more reliable job of ensuring C10's value is 0 before lua writes the next 1.

 

[I_Automation]

I still want to see those comments; that may seem like a low-ROI activity right now, but it will pay huge dividends in a couple months when the system is not readily accessible to memory.

+1 on this.


I was called by a customer I had built a few machines for over the years.


This particular machine I had never seen or worked on before - until I got online and the program was all in my standard setup and descriptions, then I saw my company name and initials on the schematic CAD blocks.


A search of my archives and - Yes, I did build that machine, but to this day do not remember it.

 

[drbitboy]

but to this day do not remember it.

been there, done that !

 

[Aaron_]

I like the idea of having lua set c10 to 1 and forgetting. So the complete signal would be c10 back to 0 from the plc. I will go ahead and add that in and adjust the lua code to reflect.

I do want lua to give the Start command. Not only with the c2 signal. At least in it's current state.

For instance, if the e stop is pressed in the middle of a tool change. During my testing last night when I would press the e stop the plc would fault out of course. DS1 would still not be = to DS2. So as soon as the fault was reset the CW motion would try to start. With the c10 in place it wouldn't let it. So that would give me a chance to move the machine to a safe position, fix what I programmed wrong, then restart the T.C. sequence.

Maybe that is the wrong approach. I'm sure it could all be fixed with code. But you all have already spent quite a bit of time in helping me along with this project and that is something else I would need a little guidance with.

My next update will include comments. I agree they are necessary for the reasons you stated.