Re: [Emc-users] Serial to Pic IO Controller

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

As near as I can tell, we're getting to the good stuff.  After working 
with hex config files for so many years of machine service, human 
readable sounds like a good thing.  You are also right though that the 
more we can compress the actual code being transmitted the more we can do 
with a single serial connection.

I'm wondering if a graphical front end in Tcl/Tk could serve as a man 
readable interpreter for the transmitted code.  We wrote something a bit 
like this with the legends on IO_Show.tcl.  It can read the signal 
definitions from the INI and create a set of legends for the indicators.  
This would make it rather easy to examine or maintain the pic end without 
the requirement that the actual communication be man readable.  If we 
built that Tcl front end carefully we would be able to run it without an 
EMC present so that this would satisify those who want to examine the 
communication without the burden of a running emc.

I believe that we should also plan for more than one pic per project.  We 
might use one of these handy little gadgets for a tool changer, a second 
for a handheld pendant, and a third for that robot parts catcher.

Fred Proctor hammered this next thought into me the first time I met with 
him.  I had a really nice set of drawings in hand when I arrived at NIST.  
They were for a lathe interface panel.  It included several toggle 
switches and rotary pots.  He didn't like maintained switches and rotary 
pots.  This next is a rough paraphrase of what he said about the 
interface I had drawn up.

When we begin to design hardware interfaces to the EMC we need to remember 
that one of the cornerstones of EMC interface has been that any device 
connected as graphical or operator panel, with the exception of E-Stop 
should allow another graphical interface or operator panel to change the 
settings within the emc. While this makes little practical difference for 
a single, small mill it is a big thing when we begin to think about 
automated or coordinated work cells.  In these situations the focus of 
human interaction with each part of the cell may change from one location 
to another.  This means no hard wired toggles and no rotary pots because 
they could not be overridden elsewhere.  Momentary buttons or bats are 
great as are rotary pulse generators.  Up/down momentary pairs would also 
work to change integer, percent, and decimal variables.

With these things in mind, I would expand the INI stuff to include the 
specific serial port characteristics.  Stuff like 

PIC_PORT0 = ttyS0
PIC_PORT0_BAUD = 9600
PIC_PORT0_PARITY = none
PIC_PORT0_EXEC = andy1.tcl

This way we can use more than one serial port at the same time if we also 
expand the variable names enough so that we name the port as well as the 
pic locations.  I'd also upcase the varname for consistency.

PIC0_OUTPUT1 = lube
PIC0_OUTPUT2 = vacuum
PIC0_INPUT1 = ESTOP

Finally if we added another variable for each of these we could pass 
commands directly to emcsh or iosh from the INI file.  That set might 
look like.

PIC0_OUTPUT1 = lube
PIC0_OUTPUT1_STATE = "emc_lube on"
PIC0_OUTPUT2 = vacuum
PIC0_OUTPUT2_STATE = "emc_mist on"
PIC0_INPUT1 = ESTOP
PIC0_INPUT1_COMMAND = "emc_estop off" "emc_estop on"

These state variables like lube and vacuum simply pass tickle a test which 
if true, turns on that pin.  The command variables are a bit more complex 
-- thus the two arugments.  The first is associated with the off state.  
The second with the on state.  The next example shows how a command might 
be implemented for an axis jog.

PIC0_INPUT2 = jog0plus
PIC0_INPUT2_COMMAND = "jogPlus 0" "jogStop 0"
PIC0_INPUT3 = jog0neg
PIC0_INPUT3_COMMAND = "jogNeg 0" "jogStop 0"

(Several readers will note that this command requires a minor modification 
to tkemc because jogStop does not take an arg as written here)  As I look 
at these now, I'm not certain that we even need the INPUT2 = xxxxx  A 
command or state variable might be enough.

Now in order to program the PC to handle these things properly, the 
integrator will need to know all of the possible emc_ type commands and 
their effects given the various states that the EMC can be in at any 
time.  That integrator will also have to know a list of possible tkemc 
variables and processes and how they cause the emc to respond as well.  I 
believe that such a list could be written into the documentation as 
suggested earlier along with specific examples of some typical INI 
configurations for the pic.

I'm not at all clear about how to handle the analog stuff.  What Jim wrote 
works and I can see with a tool changer that we might want to change the 
speed of rotation of a carousel without making it an emc axis in it's own 
right.  I can see how we might want to monitor a multitude of analog 
signals using the pic and send those values to the display.  I'm a lot 
less clear about sending the digital representation of analog values from 
the pic to the PC.

Keep talking.  I'm sure that there will be changes to what's here.

Ray 

On Monday 05 January 2004 6:08 pm, Jonathan Stark wrote:
> I'm not sure I see a reason for making the serial commands
> to and from a pic human readable.
>
> All of these examples are great in that they're easy to read,
> but in reality, what human will read the raw serial streams to care?
>
> The downside is that the bottle neck for speed is the serial
> speed.  This proposed protocol is many times slower than a single
> byte command word with data following.
>
> Maybe nobody else besides me is crazy enough to think that controlling
> stepper motors over a serial link is a good idea, but it definitely
> won't work with a verbose protocol like this, and I'd still sorta
> like that option for my slow behemoth of a mill.
>
> The pic and the linux box can both do bit operations on the data
> much more quickly than interpretting the commands below, or sending
> and receiving the commands below, so I'm still for sending 8 bit words
> at a time.  You can tell the pic to set up the direction on inputs and
> outputs, and can set masks for what you do and don't want changed if
> you like, but the bandwidth difference between "w8" and
>
> output0 on
> output1 off
> output2 on
> output3 on
> output4 on
> output5 on
> output6 on
> output7 on
> output8 on
>
> is obviously huge (2 bytes vs. at least 80)
>
> That said, I think there's probably space for both approaches.
> Have a text mode or a text super-set if you like, but also allow
> for a faster 'binary'-esq mode that transfers data a bit quicker,
> and is conscientious of the fact that the serial bandwidth is the
> limiting factor.
>
> Also, everyone should note that not *any* pin can be configured for
> input, output, or a/d, and that some pins on some pics have 'unusual'
> features, like open collector inputs, which can be a blessing or a pain
> depending on what you want to do with them.  As for needing to decide
> which pins do what, that can be configured at runtime.  The PIC
> is capable of changing many pins from input to output or a/d at
> runtime, so I don't see why we need to arbitrarily cut the flexibility
> down by declaring some dedicated one way or the other just yet.  Am
> I missing something there?
>
> I think the config file stuff here looks great, and is (hopefully)
> quite consistent with the HAL work.
>
> Jonathan
>
> Quoting Jim Fong (ji...@em...):
> > The serial command set can be made simple.
> >
> > On a 44pin PIC device, there are 33 i/o pins available to dedicate to
> > various functions.
> > I think we can afford to dedicate 8 of them as input and 8 as output.
> > The rest, the group needs to decide what other functions are
> > required.
> >
> > As for these 16 general purpose i/o, we don't really need to
> > pre-assign any particular pin to a function such as lube, vacuum etc.
> > that is up to the machine builder.
> >
> > The serial command can be as simple as
> >
> > output1 on
> > output1 off
> > output2 on
> > output2 off
> > .
> > .
> > .
> > output8 on
> > output8 off
> >
> > To read the status of one of the input pins, the serial command sent
> > can be "input1" and the PIC will send a string back to the PC such as
> > "input1 LOW" or "input1 HIGH"
> >
> >
> > Where we do assign machine functions can be in the EMC INI file or
> > whatever Ray comes up with.
> >
> > Lets say we decide to hook up the lube relay to output1, vacuum relay
> > to output2, ESTOP to input1
> >
> > the INI file can have a configuration such as
> >
> > PIC_output1 = lube
> > PIC_output2 = vacuum
> > PIC_input1 = ESTOP
> >
> >
> > The front end GUI such as tkEMC will then know which machine function
> > is mapped to each PIC i/o pin and can act accordingly.
> >
> > Hit the lube button on the gui and EMC will send a "output1 on"
> > command out the serial port.  All the PIC does is listen and when it
> > receives the "output1 on" command, it turns on the appropriately
> > assigned i/o pin i.e. the lube relay turns on.
> >
> > Other serial commands can be
> >
> > Spindle1=XXX  where XXX is 0-100, to set the speed of spindle.
> > analog1  read in A/D analog input channel 1
> > DAC1=46  Set channel 1 DAC output voltage to 4.6 volts
> >
> > As far as I know, no PIC's have built in D/A converters but we can
> > simply add a external Maxim or Analog Devices DAC chip into the
> > design.
> >
> > Jim
> > www.embeddedtronics.com
> >
> >
> > -----Original Message-----
> > From: emc...@li...
> > [mailto:emc...@li...]On Behalf Of Andy
> > Holcomb Sent: Monday, January 05, 2004 3:24 PM
> > To: emc...@li...
> > Subject: Re: [Emc-users] Serial to Pic IO Controller
> >
> >
> > would this be something we could start with for the serial cmnds back
> > and forth?  This would cover most of what needs to be done, not
> > including tool changers, we could add that I just don't know what it
> > takes.
> >
> > Andy
> >
> >
> > Serial string from EMC
> >
> > Cmnd X Position is
> > Cmnd Y Position is
> > Cmnd Z Position is
> > Set Spindle Speed to
> > Turn Cutting Fluid On
> > Turn Curtting Spray On
> > Mode (man,mdi,auto)
> > current auto state(none,running, paused, done)
> >
> > So laying that out would look like this
> > xpos,ypos,zpos,spindlespd,CutFldOn,CutSprayOn,mode,autostate
> >
> > and some fake numbers, like this
> > 2.0912,3.4567,-0.5067,1000,1,0,2,1
> >
> > Cmnd X Position is    2.0912
> > Cmnd Y Position is    3.4567
> > Cmnd Z Position is     -0.5067
> > Set Spindle Speed to    1000
> > Turn Cutting Fluid On     yes
> > Turn Curtting Spray On    no
> > Mode (man,mdi,auto)        auto
> > current auto state(none,running, paused, done)    running
> >
> >
> >
> >
> >
> > Serial string to EMC from Pic or other device
> >
> > move to X Position
> > move to Y Position
> > move to Z Position
> > make move to above position
> > Spindle Speed is
> > Cutting Fluid is On
> > Cutting Spray is On
> > Set mode to (man,mdi,auto)
> > Set Auto state to (run, pause , resume, step)
> >
> >
> > So laying that out would look like this
> > xpos,ypos,zpos,makeMove,spindlespd,CutFldOn,CutSprayOn,mode,autostate
> >
> > and some fake numbers, like this
> > 1.51,2.4567,-0.25067,1,1000,1,0,2,0
> >
> > move to X Position          1.51
> > move to Y Position            2.4567
> > move to Z Position            -0.25067
> > make move to above position         yes
> > Spindle Speed is                   1000
> > Cutting Fluid is On                yes
> > Cutting Spray is On               no
> > Set mode to (man,mdi,auto)            auto
> > Set Auto state to (none,run, pause , resume, step)     none
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: IBM Linux Tutorials.
> > Become an expert in LINUX or just sharpen your skills.  Sign up for
> > IBM's Free Linux Tutorials.  Learn everything from the bash shell to
> > sys admin. Click now!
> > http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> > _______________________________________________
> > Emc-users mailing list
> > Emc...@li...
> > https://lists.sourceforge.net/lists/listinfo/emc-users
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: IBM Linux Tutorials.
> > Become an expert in LINUX or just sharpen your skills.  Sign up for
> > IBM's Free Linux Tutorials.  Learn everything from the bash shell to
> > sys admin. Click now!
> > http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> > _______________________________________________
> > Emc-users mailing list
> > Emc...@li...
> > https://lists.sourceforge.net/lists/listinfo/emc-users
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for
> IBM's Free Linux Tutorials.  Learn everything from the bash shell to
> sys admin. Click now!
> http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Emc-users mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-users