Re: Hardware Abstraction Layer - Rev 0.01

["David A. Frantz" <wizard-at-eznet.net>]

Hi John;

See comments below.    I believe that we are thinking almost in the same 
manner, but I'm not really advocating a full blown PLC.    Rather a more 
a limited  abstraction that does not affect servo updates.    The 
problem, in my view, with a full capability PLC is that it will in some 
way reproduce capability already in any CNC controller.

jmkasunich-at-ra.rockwell.com wrote:

>
>David Frantz wrote:
>
>  
>
>>the one thing that keeps coming back in my mind is an
>>integrated PLC.
>>    
>>
>
>Yes, I think user configurable logic is very important.
>
>  
>
>>Nothing fancy of course, just a clean
>>and easy way to map I/O between devices.     The idea
>>being to have the "PLC" update code handle writting to
>>I/O.
>>    
>>
>
>I still want all the I/O to go through the hardware layer.
>The PLC should read and modify memory variables only, with
>no need to care about how (or even if) those variables
>get out into the real world.
>
Exactly!    The solving of "logic" is seperate from I/O updates in all 
PLC's that I've worked with.    It is just a question of where the 
hardware layer is and how complex that hardware layer becomes.

>  Hardware drivers should hide
>the nitty-gritty details of the variable <--> hardware
>translation.
>
I'm not sure I agree with this, hardware drivers should handle getting 
bytes to the devices in question.   Simplicity would assure 
proliferation of such drivers.
This is why I thought that a PLC is a good prototype to implement 
hardware translation on.    The I/O update routines, the drivers that 
is, would effectively provide Hardware abstraction.    From the 
perspective of a driver, this would greatly simplfy things as you would 
only have to be concerned with bulk movement of bytes or words from the 
memory areas to the hardware.

If you consider that most PLC's, at the minimum, implement an array of 
bits for input and output (some times these are independant arrays) and 
similar arrays for multibyte objects, then it is a simple matter to map 
servo information to these arrays with PLC type instructions.   That is 
if the EMC data structures are accessable to the PLC interpeter.    EMC 
data could be thought of as special purpose registers or arrays to a PLC 
abstraction.

None of this of course would be useful if it is not fast enough.   As 
this is being described an implementation would have to be fast enough 
not to impact EMC and the realtime updates required.   This is why the 
PLC interpeter would have to be limited in my view or we will still have 
to think in terms of handling the realtime data seperatly from the rest 
of the I/O.    This is not unheard of in the real world, very few motion 
controllers or CNC controllers send axis control information through 
other software and hardware.    Maybe the answer is  a mixture where the 
loop closure data is handled differrently than the other I/O associated 
with EMC.

>
>Version 0.02 is coming as soon as I can write it up, and
>I hope to address the PLC issue there.
>
>John Kasunich
>
>  
>
I'm looking forward to your next version.    As you know I'm rather new 
to this forum, and EMC for that mattter, but find the whole thing rather 
interesting.   Attending NAMES kinda lit a fire I guess.    So at this 
moment in time I'm working on aquiring some hardware to make my first CNC.

Most of my hands on experience with CNC has been as a maintenance tech 
working on a large number of Bandit controllers, proprietary controllers 
and more recently some FANUC controllers.    The Bandits are gone now, 
they were antiques when they where on the production floor, so the 
concept of CNC on PC hardware is a new experience to me.

At this point I don't even have a handle on the EMC software's 
structure.    Experience with PLC's though has me convinced that this 
concept can play a roll in the controller.    Most important is the 
potential for simplfying the user experience.

Thanks
dave

>
>
>
>
>
>
>  
>