CL logic to make LCNC buttons work like industrial machines

Yes AB and Modicon have been the CL lovers.. But long times ago.
And yes u can also kind of CL in IEC61131. One of the 6-7 languages u can use.

Mike_Eitel wrote: Yes AB and Modicon have been the CL lovers.. But long times ago.
And yes u can also kind of CL in IEC61131. One of the 6-7 languages u can use.

Fanuc and Mitsubishi still use plc ladder logic, so that's what I was most familiar with. My background is in Applications engineering, so I always spent most of my time in front of machines, teaching people how to use them. The backend stuff is still pretty new to me, but sadly, I think I've picked up more in the last 6 months than some of the dedicated service guys in my office know after 20 years in the industry :lol:

[EDIT - I abandoned this in favor of the run/step scheme located in the HAL Examples sub-forum.  I'll come back to classic ladder once I've learned more about LCNC]

Thanks to the OP for posting this; I'd really like to have all my machines to act the same with cycle-start, feedhold, and single-block functions.

Unfortunately, I'm having some problems getting it working properly.  I'm sure I'm doing something wrong - i.e. new to LCNC and classicladder.

Anybody willing to have a shot at helping me troubleshoot this thing?  The ladder program starts & runs, and the cycle start button works.

Problem is that while I can see the single-block toggle in ladder, it doesn't seem to 'stick'.

Pressing cycle-start starts a program - OK
Pressing feedhold pauses the program - OK
Pressing feedhold again does not resume - not OK
Pressing cycle-start resumes the program

Restarting the program:
Pressing single-block and then pressing cycle-start starts the program and runs a single line, but a second cycle-start puts the program back in auto. not OK.  (single-block not persistent)

Pressing cycle-stop works OK

I've attached my version of the original .clp file and the pertinent sections of my hal file.  Note that I have to put all my net commands on two lines as dyslexia gets me if a net command has more than one thing on it.

#classicladder start/stop
net auto-mode           <=  [HMOT](CARD0).7i73.0.1.input-06-not #cyclestart
net auto-mode            =>  classicladder.0.in-00

net feed-hold           <=  [HMOT](CARD0).7i73.0.1.input-02-not #feedhold
net feed-hold           =>  classicladder.0.in-01

net program-idle        <=  halui.program.is-idle
net program-idle        =>  classicladder.0.in-02

net single-block        <=  [HMOT](CARD0).7i73.0.1.input-22-not #singleblock
net single-block        =>  classicladder.0.in-03

net mode-is-auto        <=  halui.mode.is-auto
net mode-is-auto        =>  classicladder.0.in-06

net btn-stop            <=  [HMOT](CARD0).7i73.0.1.input-04-not #cyclestop
net btn-stop            =>  classicladder.0.in-05

net auto-mode-select    <=  classicladder.0.out-00
net auto-mode-select    =>  halui.mode.auto

net cycle-start         <=  classicladder.0.out-01
net cycle-start         =>  halui.program.run

net feed-resume         <=  classicladder.0.out-03
net feed-resume         =>  halui.program.resume

net single-block-select <=  classicladder.0.out-04
net single-block-select =>  halui.program.step

net program-stop        <=  classicladder.0.out-05
net program-stop        =>  halui.program.stop

net feed-hold-select    <=  classicladder.0.out-02
net feed-hold-select    =>  halui.program.pause

Thanks,
Ralph

sorry for the late reply, just seeing this. i'll see if i can take a look at what you've got going on. 

as far as pressing feed hold again to resume, the whole purpose of my CL logic was to prevent this from happening. Feed hold should never resume motion, only cycle start. 

No worries - thanks for having a look.

Despite the 'edit' in my last update, I'm back to using the CL scheme above.  Seems to be working, more or less, but I haven't done tons of testing yet as I'm working on all the final retrofit punch-list stuff.

If you have a suggested edit I'm all ears, but I think my biggest complaint is that LCNC only pauses/steps at lines with motion.  M-codes, G4 pauses, etc. all get executed whenever a program is paused or being stepped through.

As I understand it, this is pretty-much hard-coded and not something simple to fix - and has nothing to do with your CL single-block 'mode' function.

spumco wrote:

As I understand it, this is pretty-much hard-coded and not something simple to fix - and has nothing to do with your CL single-block 'mode' function.

Indeed. There is no 1:1 link between G-code program lines and the elements in the realtime motion queue. Many codes simply set an internal G-code interpreter state, and nothing about them ends up in the motion queue until the next motion command is interpreted. 

Everything that is sent to the queue has an associated program line attached to it. But, taking the case of a standalone F command on a line of its own, that won't end up as an item on the queue (such as "STRAIGHT_FEED(........)" ) it will just be something that affects the parameters in the next STRAIGHT_FEED