Well, my emc2 ebuilds are seriously out of date, but I did have at one
time end to end builds for emc{1,2} on RTLinux. I started playing
around with emc on RTAI, but did not polish them up to the same point...
So, XENOMAI and RT_PREEMPT should not be to difficult (assuming that
they have stabilized the API}
So, the portage USE flags look like "simulation rt" with
runtime/buildtime dependencies of
sys-kernel/{rt-sources,rtai-sources,xenomai-sources,rtlinux-sources}...
Hmmm... have you taken a look at TinyCoreLinux and maybe getting a
version running on that? Might be an interesting exercise.
EBo --
On Wed, 29 Aug 2012 15:00:24 +0200, Lars Segerlund wrote:
> Hmm .. you can test that yourself, but then there are already tools
> for that kind of testing, rt-tests in the linux kernel tree :-D ,
> check out the rt-wiki ... however different tools gives different
> values most time ... ( it's true, time is relative ).
> I don't remember if they did a libfor those tools , in that case one
> can use it to test..... best of both worlds.
>
> Still I like the idea of a simulator, that means you can run a
> rt-preempt built binary without rt-preempt ( ans worse timing , but
> with nice pictures :-D ) ... and with preempt you can run hardware.
>
> Now I really think the LiveCD is good, and I don't want to drop
> support for RTAI, XENOMAI, RTLinux .... or whatever, since they fill
> a
> slightly different need. Especially since ( as has been pointed out
> )
> rt-preempt has a big penalty on small ARM platforms since the
> interrupts runs in threads ( kernel threads that is ) which incur the
> cost of a context switch .... and the same for some other systems
> needing short time in the feedback loop.
>
> / Lars
>
>
> 2012/8/29 EBo <[email protected]>:
>> Why just the simulator. When we really get PREEMPT working, then it
>> can also run a machine. What would be nice is if we had some simple
>> analytical tool that would run with the latency tester that would
>> give
>> some indication on how fast the motors can move/track on a given
>> installation...
>>
>> EBo --
>>
>> On Wed, 29 Aug 2012 14:16:27 +0200, Michael Haberler wrote:
>>> EBo,
>>>
>>> I have no opinion on gentoo vs other distros
>>>
>>> However, I think creating a LinuxCNC *simulator* package and
>>> pushing
>>> this into some repo stream whould be a great way to improve
>>> LinuxCNC
>>> visibility - the CD requirement is a bit of a turnoff for a casual
>>> evaluator.
>>>
>>> A bit like giving away drugs in front of the school.. the first
>>> shot
>>> is free ;)
>>>
>>> -m
>>>
>>>
>>> Am 29.08.2012 um 14:02 schrieb EBo:
>>>
>>>> If we moved to the Gentoo platform I would be willing to develop
>>>> ebuilds to maintain it. Actually I have a set, but they are out
>>>> of
>>>> date
>>>> at this point. It has also been awhile, but I have sunrise
>>>> overlay
>>>> access and am willing to work on becoming an official gentoo
>>>> developer.
>>>>
>>>> EBo --
>>>>
>>>> On Wed, 29 Aug 2012 13:34:36 +0200, Michael Haberler wrote:
>>>>> as discussed in the context of Daniel Rogge's proposed parameter
>>>>> patch, I have moved ahead with redis integration into master.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> http://git.mah.priv.at/gitweb/emc2-dev.git/shortlog/refs/heads/redis-integration
>>>>> now has all the footwork to integrate and build redis-server,
>>>>> redis-cli, the hiredis C API, and the Python bindings from a
>>>>> snapshot.
>>>>> It also contains linuxcnc.in changes to by default start
>>>>> redis-server
>>>>> when running linuxcnc. This branch does not contain any code in
>>>>> LinuxCNC which actually uses redis; it's just the parts kit
>>>>> needed
>>>>> to
>>>>> do so.
>>>>>
>>>>> see README here.
>>>>>
>>>>>
>>>>>
>>>>> http://git.mah.priv.at/gitweb/emc2-dev.git/blob/f7352315a7153166518ffe6efbcd2caaee021780:/src/redis/README
>>>>>
>>>>> This is a lot of lines of C and then some other languages. It is
>>>>> a
>>>>> stopgap measure until we build on a platform which can apt-get
>>>>> the
>>>>> packages which just arent available for 10.04. This branch builds
>>>>> also
>>>>> on 8.04.
>>>>>
>>>>> I will clean this branch a bit, and merge it into master in the
>>>>> coming days.
>>>>>
>>>>> ---
>>>>>
>>>>> As for using redis, I'm working on redoing Daniel Rogge's patch
>>>>> to
>>>>> use redis, and this progresses nicely. The foundations work, the
>>>>> whole
>>>>> thing is unpolished, and parameter persistence to replace emc.var
>>>>> isnt
>>>>> in place yet. Daniel & folks have signed up as guinea pigs ;)
>>>>>
>>>>> For the curious, the WIP branch is here:
>>>>>
>>>>>
>>>>>
>>>>> http://git.mah.priv.at/gitweb/emc2-dev.git/shortlog/refs/heads/redis-params
>>>>> . It is based on the above, but is not ready for merging yet. The
>>>>> finished branch will contain examples to use this API from
>>>>> Python,
>>>>> standalone and in a PyGTK app. It is in principle possible to
>>>>> integrate this into a TkInter app too, based on the twisted
>>>>> tkinter
>>>>> reactor. That I would add only if I get a clear indication of
>>>>> desire.
>>>>>
>>>>> so: toldya, warnedya.
>>>>>
>>>>> - Michael
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
