Re: Interpreter failure

[Ray Henry <rehenry-at-up.net>]

Peter

I'll take this reply by sections rather than mixing my comments into your 
post.

1.  IO_BASE_ADDRESS

Fred P wrote a cute little tickle process in tkio called iniLoad.  It begins 
about line 1037 and provides ini section, variable name, and a default value 
in a kind of multiline matrix.  

line 1042 -->     EMCIO IO_BASE_ADDRESS 0x278

is really three things when the foreach loop looks at it.

sec is EMCIO
var is IO_BASE_ADDRESS
def is 0x278

Then this emc command -->        set temp [emc_ini $var $sec]
reads the ini file for the value of each "var" and "sec"  in the list 
immediately above it.  

As an example of modifying this to add more info for one of your own 
processes, suppose that you wanted to use the number of axes defined for this 
machine.  You could do this by adding the line below to the list.

TRAJ AXES 3

iniLoad will then create a local variable called AXES and set it to default 
to 3 but will read the ini for the correct value and set AXES to that value 
if found.


2. expect cool stuff

Yes you can but you will need to be a bit careful not to break the essential 
core processes that must be there in order for tkio and bridgeporttask to 
cooperate. 

Say for example that you wanted to use an ultrasonic amp to weld magnets on 
plastic chocolate molds. (hi Jan)  You could use the pins dedicated to mist 
and flood because they are defined all the way through the emc from the 
interpreter to the aux parport.  

The mist command could drive a solenoid to set the magnet on the surface of 
the plastic.  The flood command could then start the ultrasonic amp.  All of 
this timing and control could be a part of the g-code program.  

g4 p0.2 g0 x1.25 y2.00 (dwell then move to weld position)
m7 (initiate solenoid to place magnet on plastic)
g4 p0.2 m8 (dwell for solenoid move followed by amp turn on)
g4 p1.0 m9 (turn off amp and retract solenoid)
(repeat for each magnet location)

It could also be written into tkio so that you only need to issue one mist 
command and it takes care of pushing the magnet into the plastic, timing the 
turn on of the ultrasonic amp, turning off the amp at the end of the weld and 
retracting the solenoid.  The timing could be handled with the after command. 
One advantage of this approach is that you do not need to use m9 with the 
result that it turns off the amp at the same time it retracts the arm holding 
the magnet.  You could turn off the amp, wait for the plastic to cool and 
then retract the arm.


3. Tickle yer fancy

Uh, yea!  Sorta.  Spindle speed is a really flexible way of sending a ton of  
data from the interpreter to whatever aux stuff you want.  Your 16 different 
possible combinations of nine valves barely scratches the surface of the 
possibles.  You've gotten your head around the notion of tricking the emc 
into doing something that was not imagined when it was written.  Must be the 
kero fumes up in the shed.

I have not played at all with the spindle stuff so I am not certain how far 
the tentacles stretch into other processes and are intertwined with them but 
I would think that you could use a single switch command based on the value 
of spindleSpeed and give it the sixteen possible values, a 0, and a default.  
Then for each value you could set up the specific pins to turn on or off.

Let's create a copy of tkio.  Call it tkio-p and begin to make changes to it 
to conform to what you want.  We can pass it round as an attachment.  Perhaps 
the first question is how are you going to turn on each of the nine valves?  
Will each have a dedicated pin on the aux parport?  

Are there other list members who want to keep up on this or should we take it 
off list?

Ray





On Tuesday 02 July 2002 02:53, Peter wrote:
> Thanks Ray this is starting to make sense now.
>
> > line 865 change // to #
> > line 877 change // to #
>
> So this should stop those annoying little "unknown command //" boxes!
>
> > The tkio file that runs during startup is in emc/plat/nonrealtime/bin so
> > change that one.  If you plan to re-compile or re-install you will also
>
> need
>
> > to change the same named file in emc/src/emcio.
>
> so you cant just change tkio.tcl and expect cool stuff to happen?
>
> > Tkio does find the defined parport in the ini file.  It will default to
>
> 378
>
> > if none is specified.
>
> OK I found that it is looking at 0x378 but not 0x278 as well like
> bridgeportio does
> have a look at my other post which I called 'tickle yer fancy'
> I believe what I am really trying to do is 'tcl/Tk me fancy'
>
> The manual gave me the impression that "tkio.tcl" could be manipulated to
> implement io functions.
>
> > In order to use tkio you will need to specify bridgeporttask so that task
> > based NML is there to pass info to the io module.
>
> can this look at fancy S-codes? (S0-S11) and pass them on?
>
> > When you use bridgeporttask and bridgeportio, you will get a warning
>
> message
>
> > saying that when you turned estop off through the gui, and emc turned
>
> estop
>
> > off, nothing happened to the state of the estop pin on the i/o parport.
>
> What
>
> > is presumed to happen here is that when estop is turned off, and i/o
>
> parport
>
> > output number 10 changes state, external hardware will pull a relay that
> > grounds the corresponding input estop signal.  When that doesn't happen,
>
> the
>
> > warning comes up.  (pretty confusing, eh!)  The purpose of this round
>
> robin
>
> > approach is so that pressing an external estop will signal the controller
> > that the machine has faulted out so it ought to also stop asap.
>
> Yes I understood why it was doing it. (so the software can shut the machine
> down)thats why I changed the polarity of the estop out bit. that seemed to
> shut it up.
>
> > Hope this helps.
>
> Yes!!
>
>
> Peter Barrett