HAL for an old time programmer
08 Oct 2020 15:25 - 08 Oct 2020 15:28 #185363
by rootboy
No, I don't think so. It should be used for custom code that has to be executed as needed during the operation of the machinery. For example, your tool changer will have to select a new tool as needed during the the operation (in my case) of a lathe.
There might be a way to do this in LinuxCNC without using ClassicLadder, but I would expect it to be much more difficult to do. And for example, the "canned" code for a tool changer will most likely be different from the one that you have.
How hard is it to program in ClassicLadder? From an old PLC programmers perspective, not horrible. Certainly no worse than what I would go through on a new platform. But there are some quirks* to be aware of:
Where to put your net connections?
If you need access to a pin from your Mesa board in LinuxCNC, then including it in your "machine.hal" makes sense (whatever you call your .hal file). For instance, here is one of my Takamatsu.hal assignments:
So here you can see that my real-world input is being assigned to a custom signal called "tool-in-pos-to-read", which I will use in ClassicLadder.
In ClassicLadder (by way of editing my "custom_postgui.hal" file) I now need to assign this signal to a ClassicLadder pin:
Giving me the cumbersome, but human readable, "net tool-in-pos-to-read" pin that I can use in ClassicLadder or LinuxCNC. I suppose all of this could have been done in custom_postgui.hal.
I could have just driven the ClassicLadder pin directly from the Mesa board pin, but now I have a name to go along with the pin to help my old memory to remember what it does (I have a two-step memory, two steps and I've forgotten what I was doing). Personal choice there.
Some signals I needed were internal LinuxCNC pins. I needed to assign them to internal ClassicLadder pins in custom_postgui.hal.
And the requested tool:
(More on this later).
Which is a "word" variable type.
There are other "canned" signals, but I didn't need them.
Elsewhere in my Takamatsu.hal file, you will find code that was generated during the initial setup using PNCconf (if you select the manual toolchanger option, which you should). Such as:
I didn't need "tool-change-confirmed" so I drove "iocontrol.0.tool-changed" in custom_postgui.hal by adding this line:
What this does is to automatically close the tool change notification box when using the MDI tab to initiate a tool change (e.g. entering "T4M6" in the MDI window command line).
So feel free to comment out what you don't need in your machine.hal file. #JEW is my marker (and JEW are my initials) for commented out code that I might want to reference later. Or more likely, when I find out that I really did need it.
It will get deleted in the final version.
*Quirks:
1) When adding a new rung, you will get a non-descript box with three lines and an "Accept" button (IIRC, I'm at home doing this). Which happens to be the same box that you will get when adding logic to your rung. Be sure to give your new rung a name otherwise ClassicLadder will not save your new rung.
2) A "Rung" in ClassicLadder is actually a grid of 10 columns by 6 rows in which you could actually put in up to six rungs. This really should be know as a "Page". No big thing, but just remember that you are not limited to one rung per "Rung".
3) Once you get a few rungs created your next rung will be below the screen. Be sure to scroll down to expose the new rung before editing it since the scroll feature will be disabled until you complete or quit the rung.
4) Loading ClassicLadder in your machine.hal file by way of the "loadrt classicladder_rt" line caused a fault that prevented LinuxCNC to load (PCW knows more about this, I found an IRC thread where he had the exact same problem). So I edited it out and added the optional method of loading "classicladder_rt" which did work
However, changing the values in the optional method brought back the same fault.
5) I found that "tool-number", which is the tool that you asked LinuxCNC to change to, would occasionally get reset to 0 during the tool change operation. This value (in my mind) should not get reset until "iocontrol.0.tool-changed" gets set to 1, which I am doing at the end of the move. This wasn't happening reliably, so I load "tool-number" into an internal ClassicLadder variable as long as "tool-number" is greater than 0 and use that instead.
As for some best practices, the best suggestion that I can give you is that if you are finding yourself in a position of fixing one bug just to only create a new one, take a step back and re-think your code and determine what you really need and how to accomplish it.
I found myself in that position when what the operation of the tool changer as I imagined it didn't match the physics of the actual machine. I could have patched the original code until the cows came home, but it probably wouldn't have worked, and would have been a mess to troubleshoot.
You see this happen pretty often in startups where the code development takes a meager amount of time compared to how long it takes to debug it.
Get to know your machine. It wasn't until I had wired up a couple of buttons for manually indexing the tool changer did I actually see (and find a way to improve) the operation. What I saw was that depending on what position I was going for, the tool changer would stop differently including bouncing back. This was caused by a large tool in one position, and nothing in the position 180 degrees away from it.
Throw everything at your code. Along with the expected codes for tool changing, try it out with ones that shouldn't work. Does it lock up your tool changer? Now's the time to find out.
"Sections" in ClassicLadder probably should be limited to PLC code that you occasionally run from within the PLC program. Again, this is a personal choice.
I'll include my working, but not completed code. I haven't been able to clean it up since my friend was exposed to Covid at work and he booted me out of his shop. He hasn't shown any symptoms as of yet, and I hope it stays that way.
A bit long-winded, but I hope that this helps.
John
Replied by rootboy on topic HAL for an old time programmer
classicladder vs hal
Not sure - is classicladder mostly for people coming from the PLC-ladder programming world? Or are there things that classic ladder does that hal can't?
No, I don't think so. It should be used for custom code that has to be executed as needed during the operation of the machinery. For example, your tool changer will have to select a new tool as needed during the the operation (in my case) of a lathe.
There might be a way to do this in LinuxCNC without using ClassicLadder, but I would expect it to be much more difficult to do. And for example, the "canned" code for a tool changer will most likely be different from the one that you have.
How hard is it to program in ClassicLadder? From an old PLC programmers perspective, not horrible. Certainly no worse than what I would go through on a new platform. But there are some quirks* to be aware of:
Where to put your net connections?
If you need access to a pin from your Mesa board in LinuxCNC, then including it in your "machine.hal" makes sense (whatever you call your .hal file). For instance, here is one of my Takamatsu.hal assignments:
net tool-in-pos-to-read <= hm2_7i92.0.7i77.0.0.input-08So here you can see that my real-world input is being assigned to a custom signal called "tool-in-pos-to-read", which I will use in ClassicLadder.
In ClassicLadder (by way of editing my "custom_postgui.hal" file) I now need to assign this signal to a ClassicLadder pin:
net tool-in-pos-to-read => classicladder.0.in-00Giving me the cumbersome, but human readable, "net tool-in-pos-to-read" pin that I can use in ClassicLadder or LinuxCNC. I suppose all of this could have been done in custom_postgui.hal.
I could have just driven the ClassicLadder pin directly from the Mesa board pin, but now I have a name to go along with the pin to help my old memory to remember what it does (I have a two-step memory, two steps and I've forgotten what I was doing). Personal choice there.
Some signals I needed were internal LinuxCNC pins. I needed to assign them to internal ClassicLadder pins in custom_postgui.hal.
net home-z => classicladder.0.in-07
net home-x => classicladder.0.in-08And the requested tool:
net tool-number => classicladder.0.s32in-00Which is a "word" variable type.
There are other "canned" signals, but I didn't need them.
Elsewhere in my Takamatsu.hal file, you will find code that was generated during the initial setup using PNCconf (if you select the manual toolchanger option, which you should). Such as:
loadusr -W hal_manualtoolchange
net tool-change-request iocontrol.0.tool-change => hal_manualtoolchange.change
#JEW net tool-change-confirmed iocontrol.0.tool-changed <= hal_manualtoolchange.changed
net tool-number iocontrol.0.tool-prep-number => hal_manualtoolchange.number
net tool-prepare-loopback iocontrol.0.tool-prepare => iocontrol.0.tool-preparedI didn't need "tool-change-confirmed" so I drove "iocontrol.0.tool-changed" in custom_postgui.hal by adding this line:
net change-complete classicladder.0.out-00 => iocontrol.0.tool-changedWhat this does is to automatically close the tool change notification box when using the MDI tab to initiate a tool change (e.g. entering "T4M6" in the MDI window command line).
So feel free to comment out what you don't need in your machine.hal file. #JEW is my marker (and JEW are my initials) for commented out code that I might want to reference later. Or more likely, when I find out that I really did need it.
It will get deleted in the final version.*Quirks:
1) When adding a new rung, you will get a non-descript box with three lines and an "Accept" button (IIRC, I'm at home doing this). Which happens to be the same box that you will get when adding logic to your rung. Be sure to give your new rung a name otherwise ClassicLadder will not save your new rung.
2) A "Rung" in ClassicLadder is actually a grid of 10 columns by 6 rows in which you could actually put in up to six rungs. This really should be know as a "Page". No big thing, but just remember that you are not limited to one rung per "Rung".
3) Once you get a few rungs created your next rung will be below the screen. Be sure to scroll down to expose the new rung before editing it since the scroll feature will be disabled until you complete or quit the rung.
4) Loading ClassicLadder in your machine.hal file by way of the "loadrt classicladder_rt" line caused a fault that prevented LinuxCNC to load (PCW knows more about this, I found an IRC thread where he had the exact same problem). So I edited it out and added the optional method of loading "classicladder_rt" which did work
#JEW loadrt classicladder_rt
loadrt classicladder_rt numRungs=12 numBits=100 numWords=10 numTimers=10 numMonostables=10 numCounters=10 numPhysInputs=10 numPhysOutputs=10 numArithmExpr=100 numSections=1 numSymbols=200 numS32in=10 numS32out=10However, changing the values in the optional method brought back the same fault.
5) I found that "tool-number", which is the tool that you asked LinuxCNC to change to, would occasionally get reset to 0 during the tool change operation. This value (in my mind) should not get reset until "iocontrol.0.tool-changed" gets set to 1, which I am doing at the end of the move. This wasn't happening reliably, so I load "tool-number" into an internal ClassicLadder variable as long as "tool-number" is greater than 0 and use that instead.
As for some best practices, the best suggestion that I can give you is that if you are finding yourself in a position of fixing one bug just to only create a new one, take a step back and re-think your code and determine what you really need and how to accomplish it.
I found myself in that position when what the operation of the tool changer as I imagined it didn't match the physics of the actual machine. I could have patched the original code until the cows came home, but it probably wouldn't have worked, and would have been a mess to troubleshoot.
You see this happen pretty often in startups where the code development takes a meager amount of time compared to how long it takes to debug it.
Get to know your machine. It wasn't until I had wired up a couple of buttons for manually indexing the tool changer did I actually see (and find a way to improve) the operation. What I saw was that depending on what position I was going for, the tool changer would stop differently including bouncing back. This was caused by a large tool in one position, and nothing in the position 180 degrees away from it.
Throw everything at your code. Along with the expected codes for tool changing, try it out with ones that shouldn't work. Does it lock up your tool changer? Now's the time to find out.
"Sections" in ClassicLadder probably should be limited to PLC code that you occasionally run from within the PLC program. Again, this is a personal choice.
I'll include my working, but not completed code. I haven't been able to clean it up since my friend was exposed to Covid at work and he booted me out of his shop. He hasn't shown any symptoms as of yet, and I hope it stays that way.
A bit long-winded, but I hope that this helps.
John
Please Log in or Create an account to join the conversation.
Time to create page: 0.164 seconds