Please Help-Another Turret controlled by PLC

[Aaron_]

Well drbitboy, I got your code typed out and did a test run just turning the turret by hand. well with a small piece of pipe as it takes a little force. Just to make sure I didn't type something wrong and screw it up. I used your last post as the reference.

I input a number for DS1 and added a start button so i can manually trigger the program with a limit switch. Occasionally it would fire the CCW relay for some reason. That could have been just a bug after writing to the PLC. I feel like it was.

I would input a number, hit the switch but it wouldnt release the brake to start turning CW. So i modified the last rung of code to let it unlock the brake when CW was true. It didnt trigger the solenoid to stop at any location. I'm sure its nothing and a NC should be a NO or somthing. I didnt have a lot of time to troubleshoot it tonight as i didnt get in from work until late this evening and have to be back on the road early in the morning.

I did however input a 1 for ds1 and turned the turret, it didn't trigger the solenoid so i stopped on what i know is POS 1. tried to trigger the program again and it wouldnt proceed. So it recognizes the position which is why i feel like it is something petty.

 

[Aaron_]

Thank you I_Automation. Once im happy with my finally result i will definitely implement that as a fail safe. Thank you all for taking time out of your day to help not only me but other novice's like me.

 

[drbitboy]

I would input a number, hit the switch but it wouldnt release the brake to start turning CW. So i modified the last rung of code to let it unlock the brake when CW was true.

I don't understand (not an uncommon situation ). Below is my original rung controlling the brake, and it already had an [NO CW(Y003)] as the (not-)Stop condition of the Start/Stop pattern. Maybe Y003 is not the output for running the Motor CW, or Y002 is not the Motor Brake? Hmm, you said the CCW sometimes comes on briefly, that would trigger the rung if Motor CW was off. Also, the CCW bit could come on for one scan and you might not notice it physically. Maybe add a [DS1 = DS2] instruction on rung 15 to ensure the brake does not come on when CCW has a falling edge unless the the turret is at the target position?

Anyway, good luck with it, I hope the problem is something small like an NO where and NC should be. If you print what you have to a PDF, I'll take a look at it to see if it matches mine, maybe a fresh set of eyes would help.

The first thing to check would be the DS1/2/3 values: are they as expected? DS1 should be whatever you enter (1-7 entered becomes 1-7, and 8 entered becomes 0). DS2 should be the current turret position, read from X001/2/3, again positions 1-7 should give 1-7 in DS2, and position 8 should put 0 in DS2. DS3 should be one more than DS1, so 0-6 for DS2 should put 1-7 in DS3, and 7 for DS2 should put 0 in DS3.

 

[drbitboy]

Huh. I just looked at your working code (Post #12; click here), 1.PNG, Rung 4, and that triggers the Solenoid (Y001) when DS1 matches X001/2/3, not (X001/2/3 plus 1). Try replacing the [DS3 = DS1] on my rung 12 with [DS2 = DS1], so it will be like your working code.

I implemented the [plus one] from the flowchart in the user manual, but I am not surprised: this would not be the first time I either mis-read, or found bogus information in, a manual.

 

[Aaron_]

I didn't meant for the comment to read like it was your fault. I apologize if it did.

The numbers seem to transfer as they should. I haven't been able to have a successful tool change just yet to be able to check ds2 as the current position. I havent had a lot of time the last couple days to mess with it either due to work.

The flow chart and diagram in the manual fouled me up too. I had to hook it up to see how it functioned and signaled before I understood it lol. I was under the impression it worked slightly different by the manual.

The motor brake should stay on when the turret locks in position then release when the CW rotation is called or the start program is called. Otherwise the turret unlocks itself due to the tension in the spring.

I changed the code back to your original and ran over it once more. I think it match's but I will post it below for you to take a look as well.

For some reason when I hit the start program switch, the brake signal doesn't energize. It energizes the CW output and that is the only output. I have the brake wired to a relay, NC position. So when the relay is off the brake itself is energized.

I cant thank you all enough for taking the time to help, I greatly appreciate it.

 

[drbitboy]

that PDF is missing a page or two in the middle, I think.


no need to apologize.


I think we may need to invert the sense of the brake output, e.g. replace the [OUT Y003] on rung 18 with a [OUT some_internal_bit] followed by a rung with summat like this: [NC some_internal_bit]--->[OUT Y003].

 

[Aaron_]

My bad, I didnt realize it did that. Here it is again. Let me know what you think.
I feel like it is something petty keeping it from working.

 

[drbitboy]

[Update: added input X008 as an Early Solenoid Trigger to allow experimenting with when is best to trigger solenoid. Refer to comments in turret002.ckp in attachment turret002.zip for details.]

Yah that Brake rung needed to be completely refactored to account for the fact I wrote it as [Brake Applied] i.e. the brake prevents motion when the Y002 output is 1, but it is actually [Brake Released] i.e. the brake allows motion when the Y002 output value is 1 i.e. it's "fail-safe," analogous to air brakes on a tractor trailer.

I made some other changes (see below) and attach the program and PDF in a .ZIP archive

• Refactor [Brake Released Y002] output logic
• Refactor DS1 and DS2 logic to eliminate use of DH1/2 tags and hexadecimal Math functions; it's not as "cool" but it is slightly easier to understand for non-bitheads.
  • Side bonus: assigning a value to DS1 outside the range [0:8] (e.g. -1) should cause continuous CW motion until a stall fault
• Improve comments
• Expand [Stall Timer] concept to [Stall Fault] alarm output (Y005) condition,
  • that will stop the current sequence, and
  • will also prevent subsequent automatic restarts of the move sequence,
  • so the alarm needs a manual reset, via input X007, to be cleared.
• Move [Stall Timer] TOF logic be near [Stall Fault] logic, for readability.

In the end, essentially all of the complex logic of this application can be modeled with either the Start/Stop or State Coil/Fault Coil patterns (cf. here).

 

[Aaron_]

Bitboy, Thank you very much. Still having 1 issue im sure youll sort out pretty quick. I'm only triggering positions 1,2,3, and 5. 4,6,7, and 8 will not lock into place. Its not recognizing the signals.

I have tried a couple different things but I cannot get it to work properly. The signals it does recognize it goes through the process like it should. Thank you greatly for all the effort you have put into this.

 

[drbitboy]

I assume you are using turret002.ckp (if not, post a PDF with what you are using)?

Is X008 a 1 or a 0?

Is DS1's value being changed to 0 after you make its value 8?

Huh, so it works when you ask for tool/position 1 or 2 or 3 or 5, but none of the others? What is the symptom? Does it end up with a stall fault (Y005 will have a value of 1)?

Well, the code should not care about which target position is requested, and it should start the search sequence any time the target position (DS1) does not match the current position as read from X001/2/3. So if it is having problems with certain positions, I can think of two possibilities:

1. There is a typo in the code that reads inputs X001/2/3 and writes to DS2. This is unlikely because position 8, with all of those inputs as 0s, would always end up with DS2 equal to 0.
   • I guess the big question here is, does DS2 increment by 1 as the CW motion moves by each tool?
2. The other possibility is if the other inputs, i.e. (5) Indexing Control Switch and (6) Locking Control Switch, are a bit dodgy and are not being detected by the PLC at* the target position (DS1).
   • So this is a hardware problem i.e. and input is not making it back to the PLC. I can't help you there.

* or before, if input [X008 Early Solenoid Trigger] is 1

Can the programming tool do a contact trace/trend of data? If we can watch how DS1, DS2, and all the inputs, vary during the sequence until the stall fault, that might be helpful.

Another diagnostic would be to
1) create a repeating 50ms timer, T4,
2) Replace all occurrences of [1 Motor CCW Y003] with an internal bit (C1, maybe?),
3) and have a rung like this:

[FONT=monospace]    C1    TD4   25      Y003[/FONT][FONT=monospace]
----] [------]<[--------( )-----[/FONT]

That will run the CW motion at half-speed, to make the process run slower, and then perhaps you can see what is going on; setting that 25 to a smaller number would slow things down even more.

Also, slowing it down might allow some of the dodgy inputs to be detected, if that is the problem.

 

[drbitboy]

It's also possible that the CW motion stop event is delivered too late, and/or momentum is carrying the turret past the DS1=DS2 condition, and so it starts going clockwise again. Are you hearing the motor stop briefly?

 

[Steve Bailey]

I haven't been following the details of the solution you guys have worked out, but not properly responding to four of the eight positions suggests to me that one of the three discrete inputs related to the position sensors is missing.
I would rotate the mechanism by hand to each of the positions and check the states of the three position inputs at each stop.

 

[Aaron_]

ok, i think that was my error. I went back over everything again and i needed to change a couple of things. Now were triggering a position on every tool number. Although they are 1 number off. If i call tool 7, It stops on Tool 8 for example.

-The solenoid should go low when the turret locks. After the CCW motion. Its staying energized.
-The Motor Lock is not energizing after the Lock Switch goes high. Its staying low through the entire program.

So only a couple of small issues to sort through. Almost there.

 

[Aaron_]

I assume you are using turret002.ckp (if not, post a PDF with what you are using)?
yes

Is X008 a 1 or a 0?
X008 i am triggering via modbus to go high for sec and then turn back off. so it can then wait for a fault or tool change complete signal from the plc
(i used the turret1 example for this rung and manually set that line to which one worked)

Is DS1's value being changed to 0 after you make its value 8?
yes

Huh, so it works when you ask for tool/position 1 or 2 or 3 or 5, but none of the others? What is the symptom? Does it end up with a stall fault (Y005 will have a value of 1)?
i am still turning everything by hand so im getting stall faults since the tool change isnt fully completing. I think this was an issue I created. As i am stopping at every position now. It is 1 number off though. for instance if I call tool 7 it stops at tool 8. If i call 2 it stops on 3

Well, the code should not care about which target position is requested, and it should start the search sequence any time the target position (DS1) does not match the current position as read from X001/2/3. So if it is having problems with certain positions, I can think of two possibilities:

1. There is a typo in the code that reads inputs X001/2/3 and writes to DS2. This is unlikely because position 8, with all of those inputs as 0s, would always end up with DS2 equal to 0.
   • I guess the big question here is, does DS2 increment by 1 as the CW motion moves by each tool?
     I will check this now and report back
2. The other possibility is if the other inputs, i.e. (5) Indexing Control Switch and (6) Locking Control Switch, are a bit dodgy and are not being detected by the PLC at* the target position (DS1).
   • So this is a hardware problem i.e. and input is not making it back to the PLC. I can't help you there.

* or before, if input [X008 Early Solenoid Trigger] is 1

Can the programming tool do a contact trace/trend of data? If we can watch how DS1, DS2, and all the inputs, vary during the sequence until the stall fault, that might be helpful.
I will have to look into this as this is my first time doing anything PLC related so im only familiar with the functions weve been using.

Another diagnostic would be to
1) create a repeating 50ms timer, T4,
2) Replace all occurrences of [1 Motor CCW Y003] with an internal bit (C1, maybe?),
3) and have a rung like this:

[FONT=monospace]    C1    TD4   25      Y003[/FONT][FONT=monospace]
----] [------]<[--------( )-----[/FONT]

That will run the CW motion at half-speed, to make the process run slower, and then perhaps you can see what is going on; setting that 25 to a smaller number would slow things down even more.

Also, slowing it down might allow some of the dodgy inputs to be detected, if that is the problem.

I will use this, As ive been turning everything by hand and turning the timers up to give me time to manually turn everything.

 

[Aaron_]

Ok, So ds2=current position. Is updating as i spin the turret with the correct tool number.
DS=1 called tool is updating with the tool number i write to it.
The solenoid is firing after the tool has passed for some reason. ds2 and ds1 both are used on motor CW and the solenoid rungs. The numbers update correctly but after the tool passes the solenoid fires on the next tool. I will post the program below to make sure I didn't mess something up.

EDIT: i dont have the fault signal set to an ouput yet. wanted to get everything working correctly and then I will use it as an E-Stop hopefully. So if I need to e stop the machine during a tool change I can hit the e stop and it will stop the turret as well as the machine.