Can I use a C shell script for my PLC stuff?

The input pins change in both mesa and hal.The outputs dont. I can set an output with sets and it will go true and will turn the actual machine outut on. In my hal i had to set my inputs and out puts like so

net coolant.0.pb_cool_on hm2_5i20.0.gpio.051.in_not .

I could not get any other configuration to show in hal and" net pb_cool_on coolant.0.pb_cool_on=hm2_5i20.0.gpio.051.in_not" caused an error while loading emc. "coolant.0.pb_cool_on does not exist"


Im kinda stumped,any suggestions.Seems like a hal thing....

Hi

Can't see any reason why the component should not work, but have noticed your net syntax is wrong in your .hal file

Should be net <signal-name> <pin-name> <opt-direction> <opt-pin-name>

as per linuxcnc.org/docs/html/hal_basic_hal.html#r1_1_4

note that signal name and first pin are not optional.

net coolant.0.pb_cool_on hm2_5i20.0.gpio.051.in_not

This has no signal and just names 2 pins, and net will try to use the first param as a signal.

For some reason this often does not create an error when LinuxCNC loads the .hal file and starts, but either does nothing or reports that pin such and such does not exist etc.

regards

How does that go,we do it to ourselves...after a good nites sleep and finding my glass's,I noticed the pins in hal have "-" in them not " _".After changing the offending names in my hal file,all the buttons worked.This falls somewhere between amazing and duhh....

That brings me to my next "probably do'n it to myself".I have the following code to move my turret.It is a ruff write and will probably miss the actual tool,as it needs a delay to seat,Ill get to that next.I have a considerably nicer routine with error messages ect,but one battle at a time...This installs and compiles.


component turret;

pin in s32 turret_pos_m; // out put of bcd encoder
pin in bit ls_turret_up; // limit switch to indicate if the turret is seated
pin in bit tc_call; // connected to iocontrol.0.tool-change
pin in s32 current_tool; // connected to iocontrol.0.tool-number
pin in s32 next_tool; // connected iocontrol.0.tool-prep-number,tool #called by m6

///outputs///

pin out bit sl_turret_index; //connected to turret up/index solinoid
pin out bit sl_turret_stop; //connected to turret stop/seat solinoid
pin out bit tc_complete; //connected to iocontrol.0.tool-changed
variable char t_state;

variable char turret_ready;
variable bool change_tool;
variable char tool_changed;
variable char turret_error;
variable char turret_state;


function _ nofp;
license "gpl";
;;


FUNCTION(_)
{


if((tc_call)==1&&(turret_pos_m)!=(next_tool)&&(next_tool)<=8) ///check to see if tc is requested
{
change_tool=1;
}
else
{
change_tool=0;
}
{
while((turret_pos_m)!= (next_tool)&&(change_tool)==1)
sl_turret_index=1;
}

if((turret_pos_m)==(next_tool))
{
sl_turret_stop=1;
sl_turret_index=0;
sl_turret_stop=0;
}

if((turret_pos_m)==(next_tool)&&(ls_turret_up)==1)
{
tc_complete=1;
change_tool=0;
}

}

Now for the problem,when a tool change is called via M6 in mdi,the tool change flag( iocontrol.0.tool-change),never goes high and cosequently the turret never tries to move.The machine is homed and the tool # that is called by M6 updates to iocontrol.0.tool-prep-number,tool .There is no way to tell the emc what the current tool is and emc says "no tool".Where did I go wrong?and thanks...

I made a loop back as was suggested and inputs and outputs are now being read,next problem,when i attempt to run the code the Emc goes into estop and Linux locks up.Any Idea what might cause this.I keep looking over my code and it's simple and to the point.I suspected maybe a problem in the while state ment,but I dont see any thing...suggestions??


FUNCTION(_)
{


if((tc_call)==1&&(turret_pos_m)!=(next_tool)&&(next_tool)<=8) /*check to see if tc is requested*/
{
change_tool=1;
}
else
{
change_tool=0;
}
{
while((change_tool)==1&&(turret_pos_m)!=(next_tool))
sl_turret_index=1;
}

if((turret_pos_m)==(next_tool))
{
sl_turret_stop=1;
sl_turret_index=0;
sl_turret_stop=0;
}

if((turret_pos_m)==(next_tool)&&(ls_turret_up)==1)
{
tc_complete=1;
change_tool=0;
}

}

I dont think you can have a while statement that waits an indefinite period in a comp,
as each time the comp is invoked, it must fall through in << than the thread time
(without looking closely, I think you could just replace the while with an if)

Thanks for the help. I have had no luck getting the following to compile:

param rw s32 state =- 1;

It forces this error with the whole program at compile time

ke[1]: Entering directory `/usr/src/linux-headers-2.6.32-122-rtai'
CC [M] /tmp/tmp_l5PxK/turret.o
turret.comp:35: error: expected ‘{’ before ‘(’ token
turret.comp:35: error: expected ‘;’, ‘,’ or ‘)’ before ‘long’
make[2]: *** [/tmp/tmp_l5PxK/turret.o] Error 1

I had to asign the state like so
;;;
int state = -1;

Any suggestions as to why a parameter throws an error? I will also need a timer to allow the turret plate to drop down.How do I make one?I saw something about fperiods but no explanation.I would guess a sleep statement wont work in a real time function.


The code

component turret;

pin in s32 turret_pos_m; // out put of bcd encoder
pin in bit ls_turret_up; // limit switch to indicate if the turret is seated
pin in bit tc_call; // connected to iocontrol.0.tool-change
pin in s32 current_tool; // connected to iocontrol.0.tool-number
pin in s32 next_tool; // connected iocontrol.0.tool-prep-number,tool #called by m6

///outputs///



pin out bit sl_turret_index; //connected to turret up/index solinoid
pin out bit sl_turret_stop; //connected to turret stop/seat solinoid
pin out bit tc_complete; //connected to iocontrol.0.tool-changed








function_nofp;
license "gpl";
;;

int state = -1;
int wait_two = 0;



FUNCTION(_)
{

switch (state) {
case -1:
if((tc_call)==1)
{
state=0;
}
case 0:
if((turret_pos_m)!=(next_tool)&&(next_tool)<=8)
{
state=1;
sl_turret_index=1;
}
break;
case 1://rotate da turret
if((turret_pos_m)==(next_tool))
{
state=2;
sl_turret_stop=1;
sl_turret_index=0;
}
break;
case 2:///wait for the turret to seat
if((turret_pos_m)==(next_tool)&&(ls_turret_up)!=1)
{
state=3;
wait_two=75;
sl_turret_stop=0;
}
break;
case 3: //make sure da turret is seated
if((turret_pos_m)==(next_tool)&&(ls_turret_up)==1)
{
state=0;
tc_complete=1;
}
break;
case 4: //errors in case da turret aint seated
if((turret_pos_m)==(next_tool)&&(ls_turret_up)==0)
{
rtapi_print_msg(RTAPI_MSG_ERR, "Turret unseated,limit switch false");
}
else
if((turret_pos_m)!=(next_tool) && (ls_turret_up)==1)
{
rtapi_print_msg(RTAPI_MSG_ERR, "Current tool does not match commanded tool");
}
break;
case 5: break;

default: state=4;
break;
}

}

Hi,

Thanks for the help. I have had no luck getting the following to compile:
param rw s32 state =- 1;

If you do comp turret.comp and generate a C file you should soon see why you should not have a variable called state.

state is the name of the struct which holds all the pins and parameters declared in your header, and doubtless clashes with your param.

There is no real reason to have a param to hold the the current 'state', but it is useful for debugging certainly.

I called that variable progress-level in my components, set it as a param whilst developing ( as I did with several other variables until the debugging stage was over, so as to be able to easily monitor them) and then made it a local int variable.

I will also need a timer to allow the turret plate to drop down.How do I make one?I saw something about fperiods but no explanation.

I used an existing component called timedelay and created a couple of pins to connect to it from the toolchanger, to cater for a similar requirement to wait for the ATC to reverse and lock against the pawl before cutting the power to its motor.

See wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Con...oolchanger_component where you can download the code for exact details

I would guess a sleep statement wont work in a real time function

No you should avoid sleep() and usleep().
Where I have wanted a very short pause I have used an incrementing counter eg something like -The duration is obviously dependent upon the speed of the thread.

You are almost there, I learnt a huge amount from similar travails

regards