Can't find the SVs for various things

[AMDlloydsp]

I'd like to start fiddling with controlling outputs on the AIODC myself through macros.

I cannot seem to find a list of SVs mapped to numbers accessible by M94/95 in any of the docs that cover all the outputs, much less the majority of the inputs.
I understand they are from 1 through 128... but I can't find 'em (well... a very short handful, but not all).

I've gone over the AIODC manual, the programming manual, and the forum. If they're there, I've missed them several times.

Ideally, I'd like to control any of OUT1-OUT9 and read any input, but especially right now, OUT6 and OUT9. ALL the i/o SVs, as mapped to the M functions would be nice! The CNC11 manual refers to the PLC section of the "service manual", but I can't find that, either. <G>

Help???

Thanks,
Lloyd

[AMDlloydsp]

Studying a bit more last night, it appears the system variables that are mapped into M94/95 and M100/101 are not contiguous, according to the IO number on the PLC.

For instance, OUT6 appears to be mapped to SV=4, as represented in the sample macros mfunc10.mac and mfunc11.mac, which turn on/off the clamp output.

I noted that the PLC outputs DO seem to also be mapped into SVs 60001-61312, and the inputs into SVs 50001-51312.

When I attempt to set one via (say) #60006=0, I get a "variable is read-only". So, I guess the question is where are the writable copies of these outputs' SVs stored?

Finally... I note that the spindle brake in the BOSS version of the control is turned on/off by a "one shot" routine. My interpretation of that is that it simply asserts the output, but does nothing to prevent its further being controlled.

Does this mean I may override that output current state with a custom macro, and still ALSO have manual override control over it with the AUX3 key (as presently configured)?

Thanks,
Lloyd

[cncsnw]

The term "System Variable" can mean two different things on a Centroid system.

CNC System Variables are used in CNC and macro programming, and are described in the list in Chapter 11 of the Mill Operator's manual. Those include things like "#4109" for accessing the last F value given in the CNC codes, or "#50001" for accessing the current state of input #1 on the PLC.

PLC System Variables are predefined tokens in the PLC language, mapped to various system functions. They are described in the PLC Programming Manual. In the PLC program, inputs and outputs are not system variables.

Inputs and outputs are referenced in the PLC program simply with their native names (e.g. "INP11") or preferably with the names given them in the definitions section of the program (e.g. "EStopOk").

The PLC system variables "SV_M94_M95_1" through "SV_M94_M95_128" are one-bit locations which transmit requests from the CNC program (or a CNC macro called from the CNC program) to the PLC program.

For example, in a default mill installation, there are M10 and M11 macros which contain the lines "M94/4" and "M95/4" respectively. Given those macros, the M10 code will set (turn on) SV_M94_M95_4, and the M11 code will reset (turn off) SV_M94_M95_4.

It is entirely up to the PLC program to look at the SV_M94_M95_xx bits and decide what, if anything, to do about them.

A default mill PLC program gives the name "M10" to SV_M94_M95_4; gives the name "Clamp" to OUT6; and includes a line of ladder logic which reads:
IF M10 THEN (Clamp)
That line is the only thing that makes an association between "M10" or "M94/4" in a CNC program, and the action of the OUT6 relay on your PLC board.


If you are looking for CNC system variables you can write to in order to directly make PLC outputs turn on and off, they aren't there. The CNC program can only send a polite request to the PLC program (via M94/M95, or in some cases via Machine Parameter value settings). It is always up to the PLC program logic to translate CNC program requests to physical output actions.

[AMDlloydsp]

If you are looking for CNC system variables you can write to in order to directly make PLC outputs turn on and off, they aren't there. The CNC program can only send a polite request to the PLC program (via M94/M95, or in some cases via Machine Parameter value settings). It is always up to the PLC program logic to translate CNC program requests to physical output actions.
--------
Yes, thanks for confirming that. I understood all that before I asked, and I _thought_ I expressed clearly that I did (maybe not, though).

Certain system variables are _mapped_to_ various parameter numbers that the CNC system may access via parameters of the M-codes. I'm not looking to write _directly_ to the hardware from the CNC program. That would be nice, but the manual describes pretty clearly how hand-offs from the CNC software to the PLC are done (via semaphore).

As I expressed in my first two posts in this thread, what I'm looking for is the mapping that M94/95 and M100/101 use to access ALL the I/Os, not merely those two given in the examples. Since they are not contiguous numbers, nor even a multiple of contiguous values, but arbitrary (apparently), there must be a map supplied in order to use them.

I might add that I've been through all the source files supplied by Ajax, and only four or five of the IOs are mapped in the code; so if they're mapped anywhere, it must be in a definitions file used in the compilation of the PLC code that they don't supply to the end-user.

It is reasonable that the CNC user might write macro functions that access the i/o bits -- through whatever direct or indirect means. That's all I'm looking for.

I really don't care which way it has to be done, I just need to be able to do it. There are some actually _dangerous_ capabilities in the control which might suit the avid experimenter, but which must be altered or disabled in a production shop. I've already lost a couple of costly cutters and workpieces to an operator who doesn't understand that you cannot re-start the g-code again after a feed hold, unless you also ensure the spindle is turning!

Rather than asking Ajax to re-write the PLC code (which might not suit their entire audience), I thought we'd handle this through our own custom macros and jog panel key-press intercepts... but I can't figure out how, yet.

Lloyd

[AMDlloydsp]

Well, further reading in the PLC programming manual leads me to believe that I need to re-compile the PLC code with some more M94/95 bits set to macro numbers, and then I will have some M94/95 parameters besides just the 4 now defined.

I haven't gone into the existing code deeply enough yet to tell, but I might also have to code some PLC instructions to actually do the read or write of the outputs I need.

(Yes, I know the hazards of compiling one's own PLC software, and I will make every effort NOT to brick it! <G> And... this won't happen until we stand down from the present very pressing project in the shop.)

Can anyone confirm what I just wrote?

Lloyd

[diycncscott]

Lloyd,

Yes, in order to change the behavior of I/O-such as mapping an m function bit (SV_M94_M95...) to turn on an output, the PLC must be modified and re-compiled.

Below is the link to the PLC programming manual

http://www.ajaxcnc.com/tech/downloads/m ... Manual.pdf

[AMDlloydsp]

Thanks, Scott. Yes, I have the manual already. That's the source from which I derived that it would be necessary to re-compile.

Like I said, THAT isn't getting done until I'm dead-certain we can have some down-time on the machine.

One other thing about that: I read somewhere about someone "bricking" their plc. Is it possible to accidentally overwrite the kernal code, or is the kernel write-protected, so that restoring the correct plc file to the cncm directory will fix anything bad we might create?

Thanks,
Lloyd

[cncsnw]

Regarding M100/M101:

There are no "system variables", either of the CNC or PLC type, required to make M100 and M101 work.

M100 and M101 are CNC program codes which wait for specified bits in the PLC program to be in a specified state.

M100/bit-number waits for the bit to be zero.
M101/bit-number waits for the bit to be one.

All the PLC's inputs, outputs, memory bits, timer status bits and stage-active bits are visible to M100 and M101 codes, without any action required from the PLC program.

For consistency, the bit-number codes are numbered using the same convention as the CNC system variable numbers for those same bits: 50000-series for inputs, 60000-series for outputs, 70000-series for memory bits, etc..

The most common use of M100/M101 is to wait for the state of a physical input point, using a bit-number code between 50001 and 50096. The input you watch for in your CNC program with M100 or M101 might not be referenced at all in the PLC program, but M100 and M101 will still work.

[cncsnw]

Lloyd wrote:

I've already lost a couple of costly cutters and workpieces to an operator who doesn't understand that you cannot re-start the g-code again after a feed hold, unless you also ensure the spindle is turning!

Somewhere around line 1400 of a typical factory-supplied PLC program you should find code something like this:

Code: Select all

;--Feed Hold Mode
; Note: the feedrate override values used here for testing against P146
; are those calculated in the previous scan.  There is no problem with that.
IF (FeedHoldKey || KbFeedHold_M) THEN (FeedHoldPD)
IF FeedHoldPD || ActivateFeedHold_M ||
   (FinalFeedOverride_W < P146Value_W && !OnAtPowerUp_M)
  THEN SET FeedHoldLED
IF !SV_PROGRAM_RUNNING || DoCycleStart || DoCycleCancel || DoToolCheck ||
   (FinalFeedOverride_W >= P146Value_W &&
    PrevFeedOverride_W < P146Value_W)
  THEN RST FeedHoldLED
IF True THEN PrevFeedOverride_W = FinalFeedOverride_W
; (FeedHoldLED will be used later to signal MPU11 to do Feed Hold)

This block turns the Feed Hold LED on the jog pendant on and off in response to the various conditions that would turn feed hold on and off.

The LED on the jog panel is not, by itself, special. The PLC logic makes use of it as a flag, though. Later in the program there is a line:

Code: Select all

IF FeedHoldLED && SV_PC_OVERRIDE_CONTROL_FEEDHOLD THEN (DoFeedHold)

which tells the MPU11 to do whatever feed hold does, in the event that the LED is on and the CNC11 software is not blocking feed hold (e.g. during a tapping cycle).

Elsewhere, typically around line 1700, there should be code similar to the following:

Code: Select all

; NOTE: SpindlePause_M allows the operator to start and stop the
; spindle with the spin start and stop keys while in a job.  In
; this case, pressing the spindle start key will only restart
; the spindle if an M3 or M4 had previously been issued and is
; still active.
IF (SpinAutoModeLED && (M3 || M4) && (SpinStopKey || KbSpinStop_M))
  THEN SET SpindlePause_M
IF ((M3 || M4) && (SpinStartKey || KbSpinStart_M) ||
    !SV_PROGRAM_RUNNING)
  THEN RST SpindlePause_M

The memory flag SpindlePause_M is later used in the logic which decides whether or not to run the spindle when an M3 or M4 request is present in Auto mode.

So, going back to the block of code which cancels feed hold:

Code: Select all

IF !SV_PROGRAM_RUNNING || DoCycleStart || DoCycleCancel || DoToolCheck ||
   (FinalFeedOverride_W >= P146Value_W &&
    PrevFeedOverride_W < P146Value_W)
  THEN RST FeedHoldLED

We are going to turn off the LED (and therefore release Feed Hold) if the program cycle has ended; if the Cycle Start key (or its keyboard equivalent) has been pressed; if the Cycle Cancel key or its keyboard equivalent has been pressed; if the Tool Check key or its equivalent has been pressed; or if the feedrate override knob was below the pause threshold, and has now been turned back up above the pause threshold.

Only the Cycle Start and Override-knob-turned-up cases are going to lead to program continuation. If you want to prevent cancellation of feed hold in those cases, when the spindle was running and is paused, then you could edit that block to read something like this:

Code: Select all

IF !SV_PROGRAM_RUNNING|| DoCycleCancel || DoToolCheck ||
   (DoCycleStart  || (FinalFeedOverride_W >= P146Value_W &&  PrevFeedOverride_W < P146Value_W)) && !SpindlePause_M
  THEN RST FeedHoldLED

That would be sufficient to get the function you want. However, it is bad form to make the control ignore a command, without giving any indication of why. Therefore you might add a message definition to the PLCMSG.TXT file:

Code: Select all

200  2200 Restart spindle before continuing!

Then, at the top of the PLC program, add a token to refer to that message (message #200, an "asynchronous" informational message):

Code: Select all

RESTART_SPIN_WARNING  IS 51202 ; (2+256*200)

And down near where you blocked cancellation of Feed Hold, add a line something like this:

Code: Select all

IF FeedHoldLED && SpindlePause_M &&
   (DoCycleStart  || (FinalFeedOverride_W >= P146Value_W &&  PrevFeedOverride_W < P146Value_W))
  THEN InfoMsg_W = RESTART_SPIN_WARNING

That way the operator is not left to wonder why the Cycle Start button is not working (provided he is smart enough to look at the messages on the screen).

Note that this logic will only help if you were running the spindle in Auto mode (with M3 or M4), and used the spindle pause feature. If you have the spindle in Manual mode, then the PLC has no way or knowing whether you meant for it to be running at any given time or not.

[AMDlloydsp]

Thanks VERY much for that! That's precisely what I need to do. My operators are - well... - operators, not 'machinists', per se. They push buttons.

That bunch of code snippets will propel me much faster toward our goal. Without it, I'm sure (in maybe weeks of fiddling) I'd have figured it out. I am experienced in programming a variety of PLCs and embedded processors... but not this one!

Thanks again. That is just the ticket.

BTW... the knowledge you display makes it seem like you're part of the Ajax or Centroid team, but I don't see anything in your handle to indicate that. Did you come by all this knowledge simply by doing it? (That's the way I learned, but it's a 'grind' sometimes...)

Lloyd