Hello guys do not know if this pertains to this but just did a recent
upgrade/update and got this on my once working config
File "hal/init.py", line 14, in <module>
import motion
File "/home/pmcs/Downloads/pmcs-sim_OLD/hal/motion.py", line 14, in
<module>
convert = rt.newinst('float2u32', 'convert.active-origin-float')
File "machinekit/rtapi.pyx", line 264, in
machinekit.rtapi.RTAPIcommand.newinst (hal/cython/machinekit/rtapi.c:5506)
RuntimeError: rtapi_newinst '('float2u32', 'convert.active-origin-float')'
failed: Operation not permitted
On Tuesday, February 7, 2017 at 5:51:47 AM UTC-6, Schooner wrote:
>
> Hi
>
> This is to advise users, that a major merge has occurred in the Machinekit
> repo.
>
> The work christened 'multicore', has been finalised and tested for the
> last few months
> and is now part of Machinekit.
>
> What is multicore?
> This talk from 2015 gives the full details.
> https://plus.google.com/events/cvhj9r8m2gh0v0kj7ccme36hlpo
>
> What do you need to do?
>
> With 3 particular exceptions, *nothing at all*, the aim has been to make
> it backwardly compatible,
> so all your configs should work as before.
>
> Please report any problems via the tracker at
> https://github.com/machinekit/machinekit/issues/1123
>
> Once any teething problems are sorted, the capabilities and enhancements
> available within the code,
> will be rolled out, documented and advised for any users wishing to make
> use of them.
>
> *Exceptions *
>
> - The primary exception is for anyone using the DE0-NANO-Soc or Zynq
> as a Mesa 5i25 replacement
>
> Improvements to the *hm2_soc_ol* driver now make use of a different
> string argument handling mechanism.
>
> In practice, this simply means editing your hal file driver instantiation
> line from
> *newinst [HOSTMOT2](DRIVER) [HOSTMOT2]DEVNAME config=[HOSTMOT2](CONFIG)*
> to
> *newinst [HOSTMOT2](DRIVER) [HOSTMOT2]DEVNAME -- config=[HOSTMOT2](CONFIG)*
>
> The 2 dashes route the config string to the driver via a safer mechanism.
> Any integer instanceparams such as 'debug=1' are passed as previously, so
> remain to the left side of the delimiter
>
> If interested, this gives more details
> https://github.com/machinekit/machinekit-multicore/issues/20
>
>
> - The multicore concept relies upon atomic operations in the C11++
> standard and newer
>
> These are supported sufficiently in gcc 4.7.2 and above in x86, which
> means the code will build under Wheezy with backports installed
>
> There is however a problem on the ARM architecture running Wheezy which
> makes it unlikely it will build
>
> All builds fine on jessie-armhf and raspbian-armhf builds appear to be OK
> too.
>
> All of which means that packages for wheezy-armhf are likely to cease to
> be updated from this point.
>
> Users are encouraged to upgrade from Wheezy, which is almost 'end of life'
> and no longer receiving new backports from Debian in any case.
>
> Should you choose not to however, the current packages will continue to
> work as at present.
>
> - Something that will only affect users who have written their own C
> components which use ringbuffers. (We have no idea if there are any out
> there.)
>
> An API change sees
> *hal_ring_detach(char *name, ringbuffer_t *rb)*
> become
> *hal_ring_detach(ringbuffer_t *rb)*
>
> regards
>
>
>
--
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 [email protected].
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.
