strange behavior in 2.6 pre 5 component
27 Jul 2014 21:47 #49187
by tkamsker
strange behavior in 2.6 pre 5 component was created by tkamsker
Hi,
i did in may my first component for a tool changer then i did a 2nd for M19 ,..
on friday i tried to integrate all on the machine but the (already tool changer did not work ) i found a solution but don't understand to 100% whats going on.
The part at end of Document section
7 -- Carousel Home Operation Timed Out
8 -- qdtoolchange.qd-auto not TRUE (Auto Mode not Selected on Quickdraw Front Panel)
""";
license "GPL";
author "Thomas K based on work of K. Cunningham";
option singleton yes;
option extra_setup yes;
// wir haben leider ein Float !! function _ nofp;
;;
typedef enum {
ERROR_NO_ERROR = 0,
ERROR_INVALID_NEW_TOOL, // 1
and later it all starts with //
FUNCTION(_) {
/* Maintain the timer. Used for hardware timouts */
timer += period;
ok if i insert the function line (coming from my 2nd component
""";
function _;
license "GPL";
it works
My question
a) why did it work earlier 2.6 pre0 and stopped after pre3 ?
b) Why is the function there necessary ?
thx in advance
i did in may my first component for a tool changer then i did a 2nd for M19 ,..
on friday i tried to integrate all on the machine but the (already tool changer did not work ) i found a solution but don't understand to 100% whats going on.
The part at end of Document section
7 -- Carousel Home Operation Timed Out
8 -- qdtoolchange.qd-auto not TRUE (Auto Mode not Selected on Quickdraw Front Panel)
""";
license "GPL";
author "Thomas K based on work of K. Cunningham";
option singleton yes;
option extra_setup yes;
// wir haben leider ein Float !! function _ nofp;
;;
typedef enum {
ERROR_NO_ERROR = 0,
ERROR_INVALID_NEW_TOOL, // 1
and later it all starts with //
FUNCTION(_) {
/* Maintain the timer. Used for hardware timouts */
timer += period;
ok if i insert the function line (coming from my 2nd component
""";
function _;
license "GPL";
it works
My question
a) why did it work earlier 2.6 pre0 and stopped after pre3 ?
b) Why is the function there necessary ?
thx in advance
Please Log in or Create an account to join the conversation.
27 Jul 2014 22:39 #49188
by ArcEye
Replied by ArcEye on topic strange behavior in 2.6 pre 5 component
Hi Thomas
I am not having much success following exactly what did not work and what fixed it
Can you share some code that previously worked, which does not now.
There have been some changes to comp, but I am not sure if they are still in the master or went into 2.6~pre.
One of the changes discussed was to do with the requirement for a FUNCTION(_) in rt components.
There are some components that do not need it.
I have 2.6_pre on another partition and can test tomorrow -if you have some code to try
regards
I am not having much success following exactly what did not work and what fixed it
Can you share some code that previously worked, which does not now.
There have been some changes to comp, but I am not sure if they are still in the master or went into 2.6~pre.
One of the changes discussed was to do with the requirement for a FUNCTION(_) in rt components.
There are some components that do not need it.
I have 2.6_pre on another partition and can test tomorrow -if you have some code to try
regards
Please Log in or Create an account to join the conversation.
28 Jul 2014 18:43 #49213
by tkamsker
Replied by tkamsker on topic strange behavior in 2.6 pre 5 component
Hi,
ok thank you
it is simple see component
(it is my first ,.. so it may be ugly )
And search for
""";
then remove the line with -> function _;
in it this was the original stage which worked before pre4
now i added the function line and it worked again ,..
but i don't know why
thx thomas
ok thank you
it is simple see component
(it is my first ,.. so it may be ugly )
And search for
""";
then remove the line with -> function _;
in it this was the original stage which worked before pre4
now i added the function line and it worked again ,..
but i don't know why
thx thomas
Please Log in or Create an account to join the conversation.
28 Jul 2014 20:48 - 28 Jul 2014 21:53 #49217
by ArcEye
Replied by ArcEye on topic strange behavior in 2.6 pre 5 component
Hi Thomas
There are differences, as comp has been changed to a program called halcompile in the master.
I did a diff on the 2.6~5 version, 2.6~1 and the one in MachineKit
MK and 2.6~1 are essentially the same and 2.6~5 now has code enforcing that component name and filename must be the same.
One of the strangest, is that a patch from a while back to expose the struct __comp_state *__comp_inst=0; has been removed again in 2.6~5.
I independently came up with the same patch when working on a component where I needed to iterate through arrays of pins and then found someone else had come up with the same thing (Dewey possibly).
If you look at the docs for comp, you will notice some differences and additions, not least that 'halcompile' starts making an appearence.
Especially note the use of FUNCTION macro
www.linuxcnc.org/docs/devel/html/hal/com...ts_with_one_function
You can write code with FUNCTION missing, so long as everything after ;; is one function
You now have the macro EXTRA_SETUP() in your comp, which I don't remember from before, so that is possibly why you previously got away with not declaring FUNCTION, but now have to.
I now know, thanks to this delving, that one of my components (paramsaver ) is not going to work with the 2.6~>5 versions of halcompile, because it relies upon access to the --comp_state struct.
I shall have to see if that was an oversight or deliberate.
Well, infact I seem to have had the foresight to write it as a C file not a comp, so panic over, it will still work![:) :)](/media/kunena/emoticons/smile.png)
regards
There are differences, as comp has been changed to a program called halcompile in the master.
I did a diff on the 2.6~5 version, 2.6~1 and the one in MachineKit
MK and 2.6~1 are essentially the same and 2.6~5 now has code enforcing that component name and filename must be the same.
One of the strangest, is that a patch from a while back to expose the struct __comp_state *__comp_inst=0; has been removed again in 2.6~5.
I independently came up with the same patch when working on a component where I needed to iterate through arrays of pins and then found someone else had come up with the same thing (Dewey possibly).
If you look at the docs for comp, you will notice some differences and additions, not least that 'halcompile' starts making an appearence.
Especially note the use of FUNCTION macro
www.linuxcnc.org/docs/devel/html/hal/com...ts_with_one_function
You can write code with FUNCTION missing, so long as everything after ;; is one function
You now have the macro EXTRA_SETUP() in your comp, which I don't remember from before, so that is possibly why you previously got away with not declaring FUNCTION, but now have to.
I shall have to see if that was an oversight or deliberate.
Well, infact I seem to have had the foresight to write it as a C file not a comp, so panic over, it will still work
![:) :)](/media/kunena/emoticons/smile.png)
regards
Last edit: 28 Jul 2014 21:53 by ArcEye.
Please Log in or Create an account to join the conversation.
28 Jul 2014 22:02 #49220
by dgarrett
git.linuxcnc.org/gitweb?p=linuxcnc.git;a...6256e7fe54b2e10dfbca
Replied by dgarrett on topic strange behavior in 2.6 pre 5 component
One of the strangest, is that a patch from a while back to expose the struct __comp_state *__comp_inst=0; has been removed again in 2.6~5.
git.linuxcnc.org/gitweb?p=linuxcnc.git;a...6256e7fe54b2e10dfbca
Please Log in or Create an account to join the conversation.
28 Jul 2014 22:12 #49222
by ArcEye
Replied by ArcEye on topic strange behavior in 2.6 pre 5 component
Thanks Dewey
The changelog for 2.6~3, which is where it looks to have happened was not very illuminating.
I suppose having a global is not best programming practice and trying to access it uninitialised would be bad.
I will just stick to writing C files for components that need access, then I can manipulate things to make the __comp_state accessible as required
regards
The changelog for 2.6~3, which is where it looks to have happened was not very illuminating.
I suppose having a global is not best programming practice and trying to access it uninitialised would be bad.
I will just stick to writing C files for components that need access, then I can manipulate things to make the __comp_state accessible as required
regards
Please Log in or Create an account to join the conversation.
Time to create page: 0.073 seconds