Re: Hardware Abstraction Layer - Rev 0.01

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

Ray Henry wrote:

> snipped
>
>A kindred spirit.  Bandit must be a joy!  I've found that servicing these CNC 
>things gives one a kind of world view that makes you look at all of the parts 
>that go into one of these things.  I've often been shown something that the 
>machine was doing or not doing and had to consider the whole range of 
>possible causes because it could be hardware, hydraulics, electrics, 
>electronics, ladder, program, or part program.  My first experience was a 
>three way "not our problem," between Hardinge, GE, and the folk who built 
>those clunky mechanical terminals. 
>
Unfortunately the bandits that I worked on were "customized", I didn't 
even have the posibility of calling the vendors.

>
>  
>
>>...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 differently than the other I/O associated
>>with EMC.
>>    
>>
>
>One reason that this is an issue at the moment is that Jon Elson has 
>developed a set of outboard hardware that is communicated with using an EPP 
>parallel port.  In order for Jon to carry both I/O and servo/stepper info on 
>the same wire, he has to mix them on the real-time side of shared memory.  
>IMO this is or was the trigger event that has caused us to look again at the 
>paths that data take through the EMC.
>
Its all a question of time, I do not know enough about emc at the moment 
to know if extra time is available at the end of a servo update loop.   
The orignal thought was that the PLC code would execute in the free time 
available after a servo update.   Thus the PLC would have to be fast.

>
>I believe that there are a few I/O bits from the real world, the logic of 
>which must be handled on the real-time side of things.  E-stop and hard 
>limits are ones that I'd like to see there.  The probe switch or pin whether 
>it is used for generating a part outline or measuring tools is another.  At 
>the same time, there are many others that I don't care a whit whether they 
>get updated in the stepper loop, servo loop, I/O loop, task loop or GUI loop. 
>Coolant and lube come to mind as examples here.  
>
At this moment in time I can't recall of any motion controller that does 
not handle a few high priority I/O directly.   It might be smarter to 
dedicate one LPT port just for these items and force lower priority I/O 
to another card.

>
>I believe that the HAL will allow us to start more than one PLC at the same 
>time.  Each will run in it's own space whether hard real, user real, or 
>whenever it can.  Don't have any external switches, don't start any.  Have 
>estop and limits start that.  Have a pendant start the module or modules for 
>that. 
>
I just had the opportunity to read some info on MatPLC, while very 
impressive it is not what I had in mind.    Leaning towards 
simplification seems like a good idea.    

> 
>
>This leads me to suggest that down the road a piece we will be forced to 
>think of more than a single processor or slice of shared memory where a bit 
>on the real time side of one device is needed by a process running on the 
>real time side of another.  Here we come to the question you posed about what 
>is fast enough.
>
That seems to be constantly the question, what is fast enough.     Some 
of the posts that I've seen in the last few days seem to indicate that 
emc can pretty much saturate a PC, If that is the case then we are not 
fast enough.    Trying to develop an impression of machine performance 
over the news group probally is not to smart, so hopefully in a few 
months I will have hands on experience.    As it is the CVS download 
seems to be taking forever, it will be interesting to see how this all 
builds on RedHat 9.

>
>Ray
>
>
>On Saturday 10 May 2003 09:53 am, Dave F wrote:
>  
>
>>Hi John;
>>    
>>
><s>
>
>
>
>  
>