Invalid argument 'num_chan=2' to instantiated component

[Daren Schwenke]

Built from source last night on my BBB.  Using RIP install.

Looks like options to pid changed, but I don't see any corresponding changes to the default config files to match:

machinekit@beaglebone:~/machinekit$ linuxcnc ../linuxcnc/configs/ARM.BeagleBone.CRAMPS-LinearDelta/CRAMPS-Monster.ini

MACHINEKIT - 0.1

Machine configuration directory is '/home/machinekit/machinekit/../linuxcnc/configs/ARM.BeagleBone.CRAMPS-LinearDelta'

Machine configuration file is 'CRAMPS-Monster.ini'

Starting Machinekit...

io started

halcmd loadusr io started

cape-universal overlay found

cape-bone-iio overlay found

CRAMPS-Monster.hal:32: 

Invalid argument 'num_chan=2' to instantiated component

NB. Use of personality or cfg is deprecated

Singleton components cannot have multiple instances

Shutting down and cleaning up Machinekit...

Cleanup done

machinekit@beaglebone:~/machinekit$

Coresponding line in file is:

loadrt pid num_chan=2

Removing num_chan=2 results in setp calls to pid failing instead.

[Michael Haberler]

> Am 29.05.2015 um 14:18 schrieb Daren Schwenke <darens...@gmail.com>:
>
> Built from source last night on my BBB. Using RIP install.
> Looks like options to pid changed, but I don't see any corresponding changes to the default config files to match:

oh - that is fallout from porting pid.c to pid.icomp (using the new instcomp tool which enables instantiation)

since the manpage was written manually but now is autogenerated, it seems the new generated manpage got lost somehow

instead of loadrt pid num_chan=2 try this:

newinst pid pid.0
newinst pid pid.1

>
> machinekit@beaglebone:~/machinekit$ linuxcnc ../linuxcnc/configs/ARM.BeagleBone.CRAMPS-LinearDelta/CRAMPS-Monster.ini
> MACHINEKIT - 0.1
> Machine configuration directory is '/home/machinekit/machinekit/../linuxcnc/configs/ARM.BeagleBone.CRAMPS-LinearDelta'
> Machine configuration file is 'CRAMPS-Monster.ini'
> Starting Machinekit...
> io started
> halcmd loadusr io started
> cape-universal overlay found
> cape-bone-iio overlay found
> CRAMPS-Monster.hal:32:
> Invalid argument 'num_chan=2' to instantiated component
> NB. Use of personality or cfg is deprecated
> Singleton components cannot have multiple instances
>
> Shutting down and cleaning up Machinekit...
> Cleanup done
> machinekit@beaglebone:~/machinekit$
>
> Coresponding line in file is:
>
> loadrt pid num_chan=2
>
> Removing num_chan=2 results in setp calls to pid failing instead.
>
>

> --
> website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
> ---
> You received this message because you are subscribed to the Google Groups "Machinekit" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+...@googlegroups.com.
> Visit this group at http://groups.google.com/group/machinekit.
> For more options, visit https://groups.google.com/d/optout.

[schoo...@btinternet.com]

On 29/05/15 13:27, Michael Haberler wrote:
>> Am 29.05.2015 um 14:18 schrieb Daren Schwenke <darens...@gmail.com>:
>>
>> Built from source last night on my BBB. Using RIP install.
>> Looks like options to pid changed, but I don't see any corresponding changes to the default config files to match:
>
> oh - that is fallout from porting pid.c to pid.icomp (using the new instcomp tool which enables instantiation)
>
> since the manpage was written manually but now is autogenerated, it seems the new generated manpage got lost somehow
>
> instead of loadrt pid num_chan=2 try this:
>
> newinst pid pid.0
> newinst pid pid.1

Or just

loadrt pid num=2

both will work

One essential difference between an instantiated component and the
legacy ones, is that the component itself does not produce multiple copies.

That is done, as required, externally.

I changed halcmd so that multiple components can be loaded in the same
manner as previously, using loadrt <component> num=NN (or
names=[name1,name2...])

There are however components like pid that used non-standard parameters
like cfg=, or personality= , which are now deprecated,
so the configs that use them will require minor alteration

Sorry for any confusion

[schoo...@btinternet.com]

On 29/05/15 14:05, schoo...@btinternet.com wrote:
>
> On 29/05/15 13:27, Michael Haberler wrote:
>>> Am 29.05.2015 um 14:18 schrieb Daren Schwenke
>>> <darens...@gmail.com>:
>>>
>>> Built from source last night on my BBB. Using RIP install.
>>> Looks like options to pid changed, but I don't see any corresponding
>>> changes to the default config files to match:
>>
>> oh - that is fallout from porting pid.c to pid.icomp (using the new
>> instcomp tool which enables instantiation)
>>
>> since the manpage was written manually but now is autogenerated, it
>> seems the new generated manpage got lost somehow
>>
>> instead of loadrt pid num_chan=2 try this:
>>
>> newinst pid pid.0
>> newinst pid pid.1
>
> Or just
>
> loadrt pid num=2

I of course mean count=2 :-[

That is what you get for rushing off a reply

I am looking at all the sample configs that use num_chan= etc and
hopefully will get them amended soon

[schoo...@btinternet.com]

On 29/05/15 14:22, schoo...@btinternet.com wrote:
>
>
> I am looking at all the sample configs that use num_chan= etc and
> hopefully will get them amended soon

Submitted a PR just now that should bring all the sample configs up to
date regards pid and also debounce which changed recently.

If there are no problems, will be available soon from the repo and a
couple of days later in packages

regards

[Daren Schwenke]

The instantiation seems to work, but then both count=2 and newinst pid still fail later at:

addf pid.0.do-pid-calcs servo-thread

[Daren Schwenke]

Ok.  Changed: 

addf pid.0.do-pid-calcs servo-thread

to look like the limit threads:

addf pid.0 servo-thread

and it started, and looks to be updating.

On Friday, May 29, 2015 at 8:18:27 AM UTC-4, Daren Schwenke wrote:

[schoo...@btinternet.com]

On 29/05/15 16:58, Daren Schwenke wrote:
> Ok. Changed:
>
> addf pid.0.do-pid-calcsservo-thread

>
> to look like the limit threads:
>
> addf pid.0servo-thread
>
> and it started, and looks to be updating.

Yes, was just going to reply with that

For some reason the function is getting exported as the component name
instead of the function name.

Cannot immediately see why that would be, other components with named
functions like gantry, export the function names gantry.0.read
gantry.0.write etc as intended

Will come back when I have figured it out

> --
> website: http://www.machinekit.io blog: http://blog.machinekit.io
> github: https://github.com/machinekit
> ---
> You received this message because you are subscribed to the Google
> Groups "Machinekit" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to machinekit+...@googlegroups.com

> <mailto:machinekit+...@googlegroups.com>.

[schoo...@btinternet.com]

On 29/05/15 17:13, schoo...@btinternet.com wrote:
>
> On 29/05/15 16:58, Daren Schwenke wrote:
>> Ok. Changed:
>>
>> addf pid.0.do-pid-calcsservo-thread
>>
>> to look like the limit threads:
>>
>> addf pid.0servo-thread
>>
>> and it started, and looks to be updating.
>
> Yes, was just going to reply with that
>
> For some reason the function is getting exported as the component name
> instead of the function name.
>
> Cannot immediately see why that would be, other components with named
> functions like gantry, export the function names gantry.0.read
> gantry.0.write etc as intended
>
> Will come back when I have figured it out

OK I have found it

A fix I made some time back to function exports had a typo in it, which
only affected single named functions:-(
There are only a handful of components that actually name a single
function, pid and at_pid being two,
all the others just use default FUNCTION(_) and that equates to
exporting the component name

I will put in a PR and will be fixed soon

Apologies for the problems

As you said in your other post, things are moving fast at present, you
guys with the up to date pulls are doing the bug catching !!

Proof of fix below

mick@INTEL-i7:/usr/src/machinekit-arceye/src/hal/i_components$ halcmd
loadrt pid
<commandline>:0: Realtime module 'pid' loaded
mick@INTEL-i7:/usr/src/machinekit-arceye/src/hal/i_components$ halcmd
show pin
Component Pins:
Comp Inst Type Dir Value Name
Epsilon Flags
32770 158 float IN 0 pid.0.Dgain 0.000010 0
32770 158 float IN 0 pid.0.FF0 0.000010 0
32770 158 float IN 0 pid.0.FF1 0.000010 0
32770 158 float IN 0 pid.0.FF2 0.000010 0
32770 158 float IN 0 pid.0.Igain 0.000010 0
32770 158 float IN 1 pid.0.Pgain 0.000010 0
32770 158 float IN 0 pid.0.bias 0.000010 0
32770 158 float IN 0 pid.0.command 0.000010 0
32770 158 float IN 0 pid.0.command-deriv
0.000010 0
32770 158 float OUT 0 pid.0.commandD 0.000010 0
32770 158 float OUT 0 pid.0.commandDD 0.000010 0
32770 158 float IN 0 pid.0.deadband 0.000010 0
32770 158 s32 OUT 0 pid.0.do-pid-calcs.time
0
32770 158 bit IN FALSE pid.0.enable 0
32770 158 float OUT 0 pid.0.error 0.000010 0
32770 158 bit IN FALSE pid.0.error-previous-target
0
32770 158 float OUT 0 pid.0.errorD 0.000010 0
32770 158 float OUT 0 pid.0.errorI 0.000010 0
32770 158 float IN 0 pid.0.feedback 0.000010 0
32770 158 float IN 0 pid.0.feedback-deriv
0.000010 0
32770 158 bit IN FALSE pid.0.index-enable 0
32770 158 float IN 0 pid.0.maxcmdD 0.000010 0
32770 158 float IN 0 pid.0.maxcmdDD 0.000010 0
32770 158 float IN 0 pid.0.maxerror 0.000010 0
32770 158 float IN 0 pid.0.maxerrorD 0.000010 0
32770 158 float IN 0 pid.0.maxerrorI 0.000010 0
32770 158 float IN 0 pid.0.maxoutput 0.000010 0
32770 158 float OUT 0 pid.0.output 0.000010 0
32770 158 bit OUT FALSE pid.0.saturated 0
32770 158 s32 OUT 0 pid.0.saturated-count 0
32770 158 float OUT 0 pid.0.saturated-s 0.000010 0
32770 s32 OUT 0 pid.funct.time 0

mick@INTEL-i7:/usr/src/machinekit-arceye/src/hal/i_components$ halcmd
show funct
Exported Functions:
Comp Inst CodeAddr Arg FP Users Type Name
32769 7f048831ca32 00000000 NO 0 user delinst
32769 7f048831c8b3 00000000 NO 0 user newinst
32770 158 7f0486e7e637 7f048828e300 YES 0 xthread
pid.0.do-pid-calcs
32770 7f0486e7da2a 7f0486e7f362 NO 0 xthread pid.funct

[Daren Schwenke]

I wouldn't be building from source, if I wasn't interested in the math improvements *now*. 

Running 8 axis on the BBB without them results in nearly immediate 'joint following errors'.

On Friday, May 29, 2015 at 8:18:27 AM UTC-4, Daren Schwenke wrote:

[John Morris]

Should be available already, for Jessie too. :)

John

[Daren Schwenke]

I can confirm this works as intended with the new format now.  Thanks.

On Friday, May 29, 2015 at 8:18:27 AM UTC-4, Daren Schwenke wrote: