custom hal component failed to compile, undeclared (first use in this function)

I did a quick copy and paste and wondered if VS code was hiding shit in the white space and geany wasn't cleaning it up. It was. back to reading on numeric constant identifiers in hal. this comp file I started with is old, very old. Would it make more sense o change the true and false to 0 and 1 as that seems to be the more modern hal version identifier for true false on/off ?? thus allowing me to get rid of the additional init issues cause by introducing true false in place of 0/1




halcompile --compile Cinturnchanger.comp
Compiling realtime Cinturnchanger.c
Cinturnchanger.comp: In function ‘_’:
Cinturnchanger.c:80:15: error: expected identifier or ‘(’ before numeric constant
#define true (1)
^
Cinturnchanger.comp:73:11: note: in expansion of macro ‘true’
Cinturnchanger.c:82:16: error: expected identifier or ‘(’ before numeric constant
#define false (0)
^
Cinturnchanger.comp:74:11: note: in expansion of macro ‘false’
Cinturnchanger.comp:80:25: error: ‘turret’ undeclared (first use in this function); did you mean ‘true’?
Cinturnchanger.comp:80:25: note: each undeclared identifier is reported only once for each function it appears in
Cinturnchanger.comp:80:32: error: ‘unlocked’ undeclared (first use in this function); did you mean ‘clock_t’?
Cinturnchanger.comp:81:32: error: ‘locked’ undeclared (first use in this function); did you mean ‘clock_t’?
Cinturnchanger.comp:94:25: error: ‘Strobe’ undeclared (first use in this function); did you mean ‘true’?
Cinturnchanger.comp:94:32: error: ‘Switch’ undeclared (first use in this function)
Cinturnchanger.comp:134:26: error: ‘BCD’ undeclared (first use in this function)
make: *** [/usr/share/linuxcnc/Makefile.modinc:115: Cinturnchanger.o] Error 1

I'll look into the pin setting issue, but this is following the design of the original code.

according to the hal comp docs, it just renames the declared variables, if they are named properly, shouldn't the parser just roll iver them ??

there's a lot of wonky behavior here, and i don't write c or python so I'm green here

Hi. The pin names in the .comp file cannot contain hyphens. Change them to underscores.

After compiling, the pins will be renamed so that in hal the names will have hyphens instead.

Also, using a int for the equates as I suggested won't work as they are bits. I think you would need a bool. Also for the #defines, don't use brackets.

I also wonder if the python preprocessing by halcompile ignores the # thinking its a comment/

someone make this make sense

component Cinturnchanger // """This component controls the Cincinannati Milacron Cinturn 12u and maybe other similar lathes. This is a highly modified and""";

pin in bit toolchange

pin in s32 toolnumber
pin in s32 currenttoolnumber
pin out bit toolchanged = false

pin out bit delaystart = false
pin in bit delaydone = false


this fails like so

halcompile --compile Cinturnchanger.comp
Cinturnchanger.comp:3:1: Trying to find one of TSTRING, STRING, ";"
Traceback (most recent call last):
File "/usr/bin/halcompile", line 1508, in <module>
main()
File "/usr/bin/halcompile", line 1478, in main
process(f, mode, outfile)
File "/usr/bin/halcompile", line 1332, in process
a, b = parse(filename)
File "/usr/bin/halcompile", line 436, in parse
p = _parse('File', a + "\n\n", filename)
File "/usr/bin/halcompile", line 424, in _parse
return runtime.wrap_error_reporter(P, rule)
File "/usr/lib/python2.7/dist-packages/yapps/runtime.py", line 440, in wrap_error_reporter
print_error(e, parser._scanner)
File "/usr/lib/python2.7/dist-packages/yapps/runtime.py", line 420, in print_error
scanner.print_line_with_pointer(pos)
File "/usr/lib/python2.7/dist-packages/yapps/runtime.py", line 230, in print_line_with_pointer
print >>out, '> ',text
TypeError: unsupported operand type(s) for >>: 'builtin_function_or_method' and 'file'


this compiles just fine, someone, make it make sense


component oracchanger """This component controls the Orac Lathe
Auto Tool Changer. M6 calls this""";

pin in bit toolchange "Receives signal that tool change required";
pin in s32 toolnumber """Receives Tx data (tool number requested)
Only allows 1-8""";
pin in s32 currenttoolnumber "Receives old tool number";
pin out bit toolchanged = false "Sends signal when tool change finished";

pin out bit delaystart = false "Starts timerdelay";
pin in bit delaydone =false "Signals timer finished";

ok made some progress, the tool change iocontrol calls need revisiting, and for some reason VScode is polluting files. so had to rebuild all of my work in geany which wasn't very difficult. I do have it building now. I need to work on my hal configuration to get the tool change calls working properly.

I'm finding some of these a bit confusing.

could someone please clear up the meaning of these parameters please , and which are required to make this work. I don't know if I should link the pocket or the tool ?  I can't prep tools, I can't prep pockets etc. So I am trying to figure out specifically which IO pins I need to connect to the new hal component.

iocontrol.0.tool-change (Bit, Out) TRUE when a tool change is requested 
this goes to the hal component to signal a tool change, requested by motion control ?


iocontrol.0.tool-changed (Bit, In) Should be driven TRUE when a tool change is completed.
this comes from the hal component to signal the tool is changed , signal goes to motion control ?


iocontrol.0.tool-number (s32, Out) Current tool number
the current tool number from the hal component piped to motion control ?


iocontrol.0.tool-prep-number (s32, Out) The number of the next tool, from the RS274NGC T-word
next tool ? or is this the requested tool ? is the motion control doing look ahead ? or is this a gcode tool prep call ? IE large chain
style tool changer or large magazine unit etc ??


iocontrol.0.tool-prep-pocket (s32, Out) This is the pocket number (location in the tool storage mechanism) of the tool requested by the most recent T-word.
this is the location in a large tool magazine ? or is this a duplicate tool call ???


iocontrol.0.tool-prepare (Bit, Out) TRUE when a Tn tool prepare is requested
is this coming from the hal component or the motion control ? what is it preparing ? isn't this already handeled by the tool request and tool request s32 number ?


iocontrol.0.tool-prepared (Bit, In) Should be driven TRUE when a tool prepare is completed.
this is coming from the hal component to the motion control ? to indicate the tool is finished ?


I am asking because it seems a lot has changed sine the original component was drafted and as such, there is some terminology difference. Just trying to figure out what exactly I need to be sending and receiving to get this thing to show me the next bug.

I really think hal, should embrace a basic, like YAB or similar.