Strange behaviour at bool variable in new 2.7 head

Hi,
i am about to open source the ATC component i wrote.
therefore i want to make it "SIM" Able - probably not everyone is using General Mechatronic cards ,..
I used a new Partition with an new linux where i fetched the latest linuxcnc version
i compiled it fine all done sim works
i adjusted al ini and hal files and now i have to compile the comp
i do get an error at the bool command.
i tried to be sure an test i found in the forum
component test "This is a test component";

pin in bit testinbit;
pin in s32 testins32;
pin out bit testoutbit;
pin out s32 testouts32;
param rw s32 testrwparam = 0;

// internal variables

variable bool testbool = false;
variable float testfloat = 0;
variable int progress_level = 0;
function _;
author "ArcEye ";
license "GPL";
;;
it also doesent work

So my question is
a) Is the variable bool gone in 2.7 ? where do i find that
b) is comp only possible at real time kernel ? (which i dont have here in that ubuntu )

or did i miss something along the way
Additional question
should i use 2.7 or better stay at 2.6 ?
best reg
thomas

Hi Thomas

Nothing has happened to comp in 2.7 I am aware of

EDIT: But yes it requires a realtime environment because it uses rt libs and rt includes (just read your question properly )

I just run a component which includes some bool variables through comp and it compiled fine.

Often the error output from comp is misleading and the line number relates to the generated C file not the comp file.
(eg an error at line 67 could actually be one at line 12 of the comp file, which is not included into the C file until the other functions are declared and initialised)

Or a syntax error higher up gives an error on a following line.

Send me a copy of the comp if you want and I will try compiling it

regards

Hi,
ok so i can not use my non rt kernel for running it in sim
ok good to know ,..
but here is the component
it uses heavily NGC files based on the racktoolchanger example for the remap
But therefore you can use that component in every situation where you need to rotate stuff like turret changer in my lathe or so ,..
just 2 switches and here you go
it is configureable on number of pockets
and it is my first component ever ,..
thomas

Well I can't test it, but it compiles cleanly, so that part is fine

You will have to see if it returns quickly enough in operation, does quite a lot on each poll.

regards

Hi,
i have the comp running on my hardware which has pci card alectronic and all stuff
see my old homepage for pictures www.tkamsker.at:8080/web/pub/anpassung-s...ng-linuxcnc-wechsler
running
my idea was to make the config SIM Able that other users can use the component and dont need to have similar config like i have.

So is there a chance to make it SIM able ? probably not on an real time kernel ?
if not i will do the sim adjustment later.
My task is now to work on the
Arm out Arm in logik
and then combine it with gmoccapy and the hardware buttons

As i mentioned it is my first component
What exactely do you mean does a lot.

the system is idle while the component works there is no single Servo / stepper action required while the component does it s duty

i hope i made the decision in the first part right to save cpu power. ?
The idea is
-> Z axis in Save position
depending on action arm in or out
action for the comp to turn carousel shortest way
then action with Z axis and clamp / unclamp
Arm in/out
Save position

So if there is a hint of improvement please let me know
thx
thomas

So is there a chance to make it SIM able ? probably not on an real time kernel ?
if not i will do the sim adjustment later.

I run sims all the time, but on a realtime kernel. You can test rt components that way, the usual shortfall is lack of input.
In the past I have set up pyVCP panels with buttons etc to simulate inputs from switches and sensors and tested rt components like that.
It works quite well

What exactely do you mean does a lot.

The component will be polled once every thread cycle, which is a very short space of time.
It needs to quickly check if anything needs doing, if not return straight away.

If something does need doing, ideally it should start it off, set a flag to show where it was and return.
Next poll, it picks up where it left off, does something or checks if it is done yet, sets a flag and returns.

This known as the state-machine model, normally run as a series of case: statements, the switch() being the flag which marks the progress level.

It is the difference between something like


which completely blocks everything else until the sensor triggers, and

which just returns to that same level every poll until the sensor is triggered, allowing every other process CPU time

Whilst your component is only operating moving carousels etc during tool changes, it is still being polled every thread period.

So the first thing to consider might be operationally equivilent to

ie. if no toolchange has been requested, nor a homing order, then just return straight away.

Just some thoughts, it is not for me to impose my programming style, just try to explain how I arrived at it

regards