View Full Version : Click PLC Experience - Few Questions
Hi,
Looking at connecting a Click PLC to my Hardinge Lathe to deal with the tool turret logic. I can use the SZGH controller however they sink everything to 0V whilst my turret sensors are all 12V.
Does anyone have some experience with these - just want to validate what I need to do before I go buy one / decide which model / version.
Thanks
I used one in my Cyclone for the tool turret.
If the SZGH can handle the logic, I'd be more inclined to make/use a buffer board to convert signals, but it depends on what exactly you're trying to accomplish.
I used one in my Cyclone for the tool turret.
If the SZGH can handle the logic, I'd be more inclined to make/use a buffer board to convert signals, but it depends on what exactly you're trying to accomplish.
Thanks. The logic isnt complicated. I have code for the tool change too, the issue is converting my tool turret sensor output (which goes high on detect) to a 0V low as this is what SZGH need. They reckon I can use a simple IC 2803IC for this too which might be easy enough but would like some options in case I need to deal with some other logic too.
Suppose my other option is to use an Arduino board, that should do the logic easily and be simple enough to code. I also need to fire a number of SSRs to drive some of the air solenoids but they are standard 10-30 V DC stuff.
I've got no complaints about the CLICK PLC and expansion module I used.
Software is pretty limited, but it does the job.
2803's would work, but I'd probably use optos, and add LEDs so you can see things working.
Although just to clarify, I take it by the turret output going high, you mean it's a PNP output where it actively drives the signal high, then goes high impedance/open circuit when not active?
Hi yes, 12V feed in, then 4 bit out. So pending what the pattern (2 go high at a time), you get 8 different turret positions.
Page 51 of this manual https://www.centroidcnc.com/downloads/centroid_HardingeManual.pdf shows the details. But yes, 'on' = 12V out.
If that's all that needs converted, I'd just make a buffer board, as it'll be far cheaper and simpler than adding a PLC into the mix.
OK, will have to research buffer board however this might be easier with a bit of code? Let me explain.
In the 'M6 Program' on the SZGH, you can define code.
This is the current code to state which Tool is active. 8 Scenarios, 4 inputs. Could I not simply swap the logic?
CASET1+X00-X01-X02-X03
CASET2-X00+X01-X02-X03
CASET3+X00+X01-X02-X03
CASET4-X00-X01+X02-X03
CASET5+X00-X01+X02-X03
CASET6-X00+X01+X02-X03
CASET7+X00+X01+X02-X03
CASET8-X00-X01-X02+X03
I might try this later but still need to complete some wiring before I Can check.
So tried this, I get no update on the T numbers but it might be related to the macro not running properly yet as it times out as I've not yet connected the actual moving bits, so it times out.
Ignore the code for a moment, and answer the electrical questions.
The turret encoder goes high when active, but does it actively switch low when not-active?
If it does actively switch low (and not just go high-impedance), then it might be able to switch the SZGH inputs directly, but it'll depend on the actual hardware inputs as to whether they'll reliably switch when they're driven to 12V instead of being left open circuit.
As long as the electrical side is switching reliably, then swapping logic is easy enough. In that code sample you posted, you just need to swap the + and -'s
Ignore the code for a moment, and answer the electrical questions.
The turret encoder goes high when active, but does it actively switch low when not-active?
If it does actively switch low (and not just go high-impedance), then it might be able to switch the SZGH inputs directly, but it'll depend on the actual hardware inputs as to whether they'll reliably switch when they're driven to 12V instead of being left open circuit.
As long as the electrical side is switching reliably, then swapping logic is easy enough. In that code sample you posted, you just need to swap the + and -'s
Yep, 12V when high and 0V when not. This is on its on Power Supply. So not using the 0V or 24V from the controller. Should I join the grounds?
Yep, 12V when high and 0V when not. This is on its on Power Supply. So not using the 0V or 24V from the controller. Should I join the grounds?
Yes, the 0V will need connected.
My only concern is how the SZGH will handle having 12V on the input. I'd think it will work OK, but I'd be checking the relevant inputs are switching cleanly.
Thanks. I'll try test tomorrow.
Some progress. Joined the 0V and get a reading. Its not correct, it only picks up one tool location and it seems the reason for this is, this is the only place where you have 2 outputs in pattern (++ --). The rest dont get picked up so I need to check their logic, there might be something else but at least one works which suggests that it detects something and changes state due to it.
Have you checked all inputs are switching on the relevant diagnostics screen?
And the inputs reflect the turret position in the manual, even if they might be flipped?
They are. Diag confirms but looks like I've not enabled the custom plc code via a tool menu. Will try it tomorrow.
So, it doesnt work. Made the change, now it recognises none of the tool locations despite being able to see the 4 bit values change. I need to look at this all again. Ive messed wiht their code too, so back to basics.
Have you got a copy of the PLC programming manual I can look at?
Yep, let me see if I upload it. HoodScotland did also link it before. I messed around again, it definately sees state change as it impacts where the turret thinks it is and stops but it doesnt show it nor match whats on the screen.
Ive also got the PLC editor and the code itself if you wanted to take a look. I can record what I see live on the machine too, what I dont understand is the relationship between the ProgramTool (M6 macro for lack of a better word) and their PLC config.
HoodScotland didnt change his PLC from what I understand. Certainly doing 4 bit to 8 discrete outputs via an Arduino might be a practical solution however this should work. The macro / turret logic is very simple.
3056330564
Documents. Ill try share the code and PLC program in a bit.
This is the macro and their explanation ....
PAUS100
STAF(Unclamp Turret!)
OUT+M63;unclamp
WAT+X06;T07,position of unclamp
STAF(Rotate & Select Tool!)
OUTPY18RY19
CASET1+X00-X01-X02-X03
CASET2-X00+X01-X02-X03
CASET3+X00+X01-X02-X03
CASET4-X00-X01+X02-X03
CASET5+X00-X01+X02-X03
CASET6-X00+X01+X02-X03
CASET7+X00+X01+X02-X03
CASET8-X00-X01-X02+X03
OUT-Y18-Y19
PAUS50
STAF(Clamp Turret!)
OUT-M63;clamp
WAT+X07; T08,position of clamp
TS(0)=TAIM
CURTS=TAIM
STATUSINFO(Tool Change is Finished!)
PAUS300
DISP
RETURN
Explanation.
M63:output for unclamp turret
reset for clamp turret
+T: CW Rotation_Turret
-T: CCW Rotation_Turret
T07: Input, Position of unlock turret
T08: Input for detecting position of lock turret
There's a few issues with their code. There is no clamp. I also do not have both forward and reverse, I can only move the turret in one direction.
Whereas the logic is simpler. My turret down detect switch doesnt seem to work, so its not wired in at the moment.
On Tool Change request (if tool doesnt match current tool), then activate an output (On Solenoid).
Keep this output on until the correct tool number is matched (this is via the 4 bit logic defined in CASET)
Then, as soon as the Toolnumber is correct, activate a 2nd output (which is the stop solenoid)
This is not the same as switching off the on solenoid. The stop solenoid actually pushes out an arm to 'stop' the turret in the right location.
It then switches off the 'on solenoid' which lowers the turret
The turret then is detected by a switch
The stop solenoid can now be turned off. Tool Change done.
M63 comes on as defined in the code, then it stops when it detects 'something' but not sure what. Certainly taking out the +X07,T07 will probably help. I need to understand where X07 is defined. T07 is probably the T07 they refer to in their instructions (input, position of unlock turret). Not sure where +X07 is defined, nor X06 for that matter.
They also use Y18 and Y19, but not sure what those are.
3056330564
PAUS100 Pause 100ms
STAF(Unclamp Turret!) ???
OUT+M63;unclamp Trigger Unclamp
WAT+X06;T07,position of unclamp Wait for input X06 to become high
STAF(Rotate & Select Tool!) Display message
OUTPY18RY19 Activate outputs Y18 or Y19 depending on nearest tool rotation direction
CASET1+X00-X01-X02-X03 These are simply a set of CASE statements, and the code simply runs until it gets a match on location
CASET2-X00+X01-X02-X03
CASET3+X00+X01-X02-X03
CASET4-X00-X01+X02-X03
CASET5+X00-X01+X02-X03
CASET6-X00+X01+X02-X03
CASET7+X00+X01+X02-X03
CASET8-X00-X01-X02+X03
OUT-Y18-Y19 Deactivate Y18/Y18 outputs
PAUS50 Pause 50ms
STAF(Clamp Turret!) Display message
OUT-M63;clamp Re-clamp turret
WAT+X07; T08,position of clamp Wait for input X07 to become high
TS(0)=TAIM Tool number on the spindle = value passed by the T command
CURTS=TAIM Current tool set number = value passed by T command
STATUSINFO(Tool Change is Finished!)
PAUS300
DISP Refresh tool status on main interface
RETURN
Explanation.
M63:output for unclamp turret
reset for clamp turret
+T: CW Rotation_Turret
-T: CCW Rotation_Turret
T07: Input, Position of unlock turret
T08: Input for detecting position of lock turret
Now I've seen the programming manual, I've added comments to the code.
Looks like the turret simply spins until there is a location match, so the turret position never actually gets read in out with a tool change command.
OK, I found an IO Mapping text document in the backed up files. So my assumptions were correct.
T01 X00
T02 X01
T03 X02
T04 X03
T05 X04
T06 X05
T07 X06
T08 X07
+T Y18
-T Y19
Noted you have replied, thanks. Yes, the problem is lack of tool location detection. In the I/O screen I can see the 4 bits change. There is a 'phase' where they read all 1 1 1 1 as the hall sensor goes from one state to the next but there is no defined 1 1 1 1 so it should ignore this.
Question is, why does it not translate inputs it can clearly see into what the screen shows. I thought it might be as its not declared early enough and it never gets that far in the code, moved it up, no difference.
I'm going to rewrite the code and take out all the stuff which is clearly not needed, maybe that allows the code to be read for the location.
I'm using M69 output to enable the Stop Solenoid.
PAUS100
STAF(Rotating Turret!)
OUT+M63;unclamp
STAF(Rotate & Select Tool!)
CASET1+X00-X01-X02+X03
CASET2-X00+X01-X02+X03
CASET3+X00+X01-X02+X03
CASET4-X00-X01+X02+X03
CASET5+X00-X01+X02+X03
CASET6-X00+X01+X02+X03
CASET7+X00+X01+X02-X03
CASET8-X00-X01-X02+X03
PAUS50
STAF(Location Found, Lower Turret!)
OUT+M69
STAF(Stop Engaged!)
PAUS250
OUT-M63
OUT-M69
TS(0)=TAIM
CURTS=TAIM
STATUSINFO(Tool Change is Finished!)
PAUS300
DISP
RETURN
What I'd probably do, is start with a basic custom macro to test tool positions.
Something like -
IF(+X00-X01-X02+X03)THEN
MESSAGEBOX(TOOL 1)
RETURN
ENDIF
Make sure the turret is on position 1, the relevant inputs are as expected, run the macro, and see if you get the message shown.
If the message doesn't show, try just the MESSAGEBOX with a basic message to ensure the macro is actually running (or try this first to save some typing!)
You could then extend the macro for other tool positions, and add in TS(0) = xx, CURTS = xx, and DISP to initialise the tool position.
Once you know you can read the tool positions correctly, then work on getting the turret to move.
Some progress. It now updates tool location as I've removed the wrong code. Can't get it to activate the stop sol however. Still looking.
Thanks. Ive got it working !!!!
Many thanks for your help.
So a few issues.
Their code wasnt right for my machine. So the logic never got to the point of updating the tool (plus I had to redo the 4 bit logic as I had their original version).You also cant use any output here, M69, M67, none worked (Yet M63 does ....).
I then used the Turret + assigned to the Stop Solenoid, that worked. Then it was just a case of getting the timings right.
Vid of it working to follow.
Next will be setting up tool offsets etc.
Many thanks once again.
I'd guess macros are limited as to what other macros they can call, to avoid locking things up.
There is probably some page in a manual somewhere that lists what you can, or can't do, and it may never even have been translated to English.
I know the section of the manual for my lathe controller covering the polygonal turning, was a fresh translation, as there was even a note on the front page requesting what pages were to be translated from the original Chinese manual.
Lathe tool offsets can be fun.
I've only recently thought about how to do mine better, as some new parts I'll be making require a bit more accuracy between tools.
My plan is to use a 50mm height gauge (the dial type you get for setting tools on mills), to set the tools 50mm from the face of the chuck, then adjust part offsets accordingly.
Off course, if you'll be using different chucks, then that won't work very well.
If you don't need high accuracy, then you can just set tools relatively to each other by facing a bit material, then jogging onto the freshly faced surface with a new tool, which will usually get you within 0.02mm accuracy if you're careful.
https://youtu.be/yAK2E5L320w
I'd guess macros are limited as to what other macros they can call, to avoid locking things up.
There is probably some page in a manual somewhere that lists what you can, or can't do, and it may never even have been translated to English.
I know the section of the manual for my lathe controller covering the polygonal turning, was a fresh translation, as there was even a note on the front page requesting what pages were to be translated from the original Chinese manual.
Lathe tool offsets can be fun.
I've only recently thought about how to do mine better, as some new parts I'll be making require a bit more accuracy between tools.
My plan is to use a 50mm height gauge (the dial type you get for setting tools on mills), to set the tools 50mm from the face of the chuck, then adjust part offsets accordingly.
Off course, if you'll be using different chucks, then that won't work very well.
If you don't need high accuracy, then you can just set tools relatively to each other by facing a bit material, then jogging onto the freshly faced surface with a new tool, which will usually get you within 0.02mm accuracy if you're careful.
Yep, on this machine I can set it to hit the home, then find the index pulse, so better repeatability. The toolsetting can be done with a probe or the 'cut and measure' method. Ironically I used the 50mm height setter too on my previous lathe, it works for some tools, not others.
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.