Page 1 of 1
Drive Fault Conditions
Posted: Wed Dec 13, 2023 11:30 am
by chronolite
I have a handful of Oak retrofits I'm working on and I'd like some information that I'm having trouble finding. Here's my questions:
What are the conditions that will raise a "drive x fault" on the oak from the drive connectors? is it only if Drive Fault (pin 19) goes high?
Which inputs are associated with the inputs on the drive connectors? (where can I see in the PLC explorer this pin 19 status?)
What conditions must be met for a Setup/137...Home... F10 action to result in home, instead of "Home not set"?
Can I move a homing minuteman, and update its position programmatically?
Can I switch parameters using code or buttons? Can I switch between precision/position and velocity modes for example?
Where can I get a list of the I/O associated with those connectors?
Are there parameters that I can change to reassign those inputs/outputs?
If not, I presume this is all done in the PLC code? Which file would this be?
If these are answered somewhere, I'd really just need pointed in the right direction.
Thanks in advance,
Buzzy
Re: Drive Fault Conditions
Posted: Wed Dec 13, 2023 11:58 am
by Centroid188
The drive fault means the drive is giving the control a drive fault message.. Which is the fault in pin on the drive header.
The pin connections to the drive are shown on page 36 of the oak install manual, these are not user or PLC definable...
https://www.centroidcnc.com/downloads/c ... manual.pdf
In order to home you must home the machine. M26 each axis with one of the homing methods. The install manual will describe this. Page 54
The PLC manual is also on the website..
https://centroidcnc.com/centroid_diy/ce ... nuals.html
The "CNC12 PLC programming manual"
You can switch between Velocity and Precision mode by changing the parameter 256. You would also have to change the associated tuning.
Re: Drive Fault Conditions
Posted: Wed Dec 13, 2023 12:48 pm
by chronolite
I'm looking for a more comprehensive answer here. I understand that OAK will issue a drive x fault if the drive raises pin 19 on that connector, but what other conditions satisfy the SV_DRIVE_STATUS_X messages?
Re: Drive Fault Conditions
Posted: Wed Dec 13, 2023 1:02 pm
by chronolite
I want to clarify my questions here a little, because I understand they could come across as sophomoric misunderstandings of the basics, but I am interested in more detail, specifically, where does SV_DRIVE_STATUS_X live? What are the conditions that change it, and where can I find this code?
As for homing the machines, I'm confused with the response "In order to home you must home the machine".
What I'm asking for is in setup, what are the conditions that lead to specifically allowing the home routines to execute. more specifically, when an installer presses "F10 Set Home" in the setup, what generates the "Home Z not set" message and can we work backwards using test driven methodology to remove these conditions, in order when the last test passes, home will be set.
And finally, my specific question about changing a parameter programmatically, let's say it's not position/precision parameter 256, let's say it's any other parameter, parameter 69 or 420 or whatever is there a way I can change it with PLC code, an AUX key or some other programmatic function, other than opening the parameter and changing it? Where are the parameters kept, in what file/location? when are they loaded? can they be reloaded on the fly? I want to learn about them. Where can I?
Re: Drive Fault Conditions
Posted: Wed Dec 13, 2023 2:12 pm
by chronolite
The system variable for SV_Drive_Status_X description in the programming manual is vague. I want to know what conditions we have to meet in order for that to be not in a state of "drive fault" and what other conditions contribute to that message.
Re: Drive Fault Conditions
Posted: Wed Dec 13, 2023 5:41 pm
by cncsnw
The Oak hardware manages the drive bus communications, and provides "SV_DRIVE_STATUS_n" based on what it read from the axis headers.
The servo drive is responsible for pulling pin 19 low (closing it to 0VDC through pin 20) when all is well. If pin 19 is open, or not pulled low, then that will be interpreted as a drive fault.
Typical PLC logic reads SV_DRIVE_STATUS_n for each drive, and unpacks it into blocks of high-numbered memory bits (e.g. MEM500 - MEM579):
Code: Select all
IF True THEN WTB SV_DRIVE_STATUS_1 Axis1StatusBit0 16,
WTB SV_DRIVE_STATUS_2 Axis2StatusBit0 16,
WTB SV_DRIVE_STATUS_3 Axis3StatusBit0 16,
WTB SV_DRIVE_STATUS_4 Axis4StatusBit0 16,
WTB SV_DRIVE_STATUS_5 Axis5StatusBit0 16
Then it makes an inverted copy of bit 15 of each of those blocks, in a lower-numbered memory bit (e.g. MEM16-MEM20):
Code: Select all
IF !Axis1DriveALM THEN (AxisDrive1Ok)
IF !Axis2DriveALM THEN (AxisDrive2Ok)
IF !Axis3DriveALM THEN (AxisDrive3Ok)
IF !Axis4DriveALM THEN (AxisDrive4Ok)
IF !Axis5DriveALM THEN (AxisDrive5Ok)
Then, if the control attempts to enable and use a drive that is in a fault condition, the PLC will trigger a drive fault condition with the accompanying message:
Code: Select all
IF SV_AXIS_VALID_1 && SV_PC_POWER_AXIS_1 && !AxisDrive1Ok
THEN FaultMsg_W = AXIS1_DRIVE_FAULT, ; 6401(1+256*25)
SET AxisFault_M,
SET Axis1Fault_M
Note that the logic that tests both SV_AXIS_VALID_n and SV_PC_POWER_AXIS_n is redundant. As far as I know, there is no condition where CNC12 would attempt to enable (power) an axis that is not valid (i.e. not set up as an active servo-controlled axis).
The double inversion, where a closed circuit on pin 19 leads to a 0 bit in SV_DRIVE_STATUS_n, then the PLC program has to translate a 0 bit in AxisnDriveALM to a 1 bit in AxisDrivenOk, is unnecessarily convoluted. I think that was eliminated in RedOak and Hickory; but is normal for Oak.
Re: Drive Fault Conditions
Posted: Mon Dec 18, 2023 9:03 am
by chronolite
Thank you, this was a really helpful missing piece of the puzzle. We (likely) have 11 of these to do asap and maybe 30+ more machines right after; we just don't have the technicians able to do the work. (We're hiring, well paying jobs in NE Ohio!) So in my spare time (lol) I'd like to come up with a test-driven methodology so the installs can be expedited; not that there's a ton of issues, but drive configuration and tuning is slowest/most complicated component of the install, we're trying to eliminate as many variables as possible. I'd still like to have a way to change parameters on the fly, programmatically.
Re: Drive Fault Conditions
Posted: Wed Dec 27, 2023 10:16 am
by chronolite
Figured it out. PM me if you want any of these answers.