On Tue, 11 Sep 2012 08:50:33 +0200, andy pugh wrote:
> On 11 September 2012 05:42, EBo wrote:
>
>> thread #1 thread #2
>> wait until flag1 unset some instruction...
>> some instruction...wait until flag1 unset
>> set flag1 some instruct
On 11 September 2012 05:42, EBo wrote:
> thread #1 thread #2
> wait until flag1 unset some instruction...
> some instruction...wait until flag1 unset
> set flag1 some instruction...
> some other instruction... set flag1
Ah. I had
Michael,
Not sure where to start or finish here. It will be interesting to see
how HAL and Thread interact to deal with critical regions I can see it
working. The question is how elegantly we can get this to work. I
think it might be as simple as a semaphore (stretched between two user
defi
On Tue, 11 Sep 2012 01:32:59 +0200, andy pugh wrote:
> On 10 September 2012 20:29, EBo wrote:
>> I do not think will work. Your blocking flag needs to be read and
>> set
>> with an atomic operation (ie. single instruction).
>
> Why isn't a block atomic in the context?
Did you intend your read/s
On 10 September 2012 20:29, EBo wrote:
> I do not think will work. Your blocking flag needs to be read and set
> with an atomic operation (ie. single instruction).
Why isn't a block atomic in the context?
--
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto
--
I do not think will work. Your blocking flag needs to be read and set
with an atomic operation (ie. single instruction). See:
Mutual Exclusion: http://en.wikipedia.org/wiki/Mutual_exclusion
Atomicity: http://en.wikipedia.org/wiki/Atomicity_%28programming%29
and Concurrency: http://en.wikipedi
Am 10.09.2012 um 15:11 schrieb andy pugh:
> Ignoring (for a moment) the means of communication, could the
> handshaking be as simple as a few more M-codes?
>
> M90 clear flags
> M91 P1 wait for blocking flag 1 to clear
> M92 P2 set blocking flag 2
> M93 P2 release blocking flag 2
eventually I
could be we're reinventing some wheel here
how do manufacturers of controls deal with synchronization?
-m
Am 10.09.2012 um 14:30 schrieb Kenneth Lerman:
> The notion of statically created HAL pins being used to represent sync
> points seems to cause a problem if sync points are within loops.
>
Ignoring (for a moment) the means of communication, could the
handshaking be as simple as a few more M-codes?
M90 clear flags
M91 P1 wait for blocking flag 1 to clear
M92 P2 set blocking flag 2
M93 P2 release blocking flag 2
--
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/
Am 10.09.2012 um 14:30 schrieb Kenneth Lerman:
> The notion of statically created HAL pins being used to represent sync
> points seems to cause a problem if sync points are within loops.
>
> They could no longer be reached monotonically.
I wrote the below, but 'undecidable' might have to be re
On Mon, Sep 10, 2012 at 1:30 PM, Kenneth Lerman
wrote:
> The notion of statically created HAL pins being used to represent sync
> points seems to cause a problem if sync points are within loops.
>
> They could no longer be reached monotonically.
When slaved, master and slave spindles would be dri
The notion of statically created HAL pins being used to represent sync
points seems to cause a problem if sync points are within loops.
They could no longer be reached monotonically.
Regards,
Ken
On 9/10/2012 2:05 AM, Michael Haberler wrote:
> Actually I can think of a much simpler solution wh
Actually I can think of a much simpler solution which is doable right now
(multiple LinuxCNC2 instances) with a Python HAL user component.
The difference to what I laid out in my previous mail is: synchronisation is
achieved at the HAL pin level, not at the 'precondition for issuing a message'
Am 10.09.2012 um 04:56 schrieb EBo:
> On Sat, 8 Sep 2012 14:10:27 +0200, Michael Haberler wrote:
>> Am 08.09.2012 um 12:46 schrieb Dave Caroline:
>>
>>> While people are dreaming of new things for a version 3
>>> I thought I would throw in a few items.
>>> I was staring at the sliding head think
Which reminds me of Citizens recent sliding head machines
they have two spindles opposite each other
front spindle will have all its operations done then the rear spindle
moves to hold the item
while it is parted off, during this time the two spindles are synchronised.
after parting the rear spind
On Sat, 8 Sep 2012 14:10:27 +0200, Michael Haberler wrote:
> Am 08.09.2012 um 12:46 schrieb Dave Caroline:
>
>> While people are dreaming of new things for a version 3
>> I thought I would throw in a few items.
>> I was staring at the sliding head thinking of the "right thing to
>> do"
>> and real
I had better mention the multi spindle automatics also
Here there are N (often 6 or 7) spindles that are mounted on a central core
that indexes to the stations where the x and z axes and tooling are.
I have seen recent cnc versions and they are really getting complex
with live tooling etc
an old
Am 08.09.2012 um 12:46 schrieb Dave Caroline:
> While people are dreaming of new things for a version 3
> I thought I would throw in a few items.
> I was staring at the sliding head thinking of the "right thing to do"
> and realised that the machine has interleaving of motion as well as
> coordin
While people are dreaming of new things for a version 3
I thought I would throw in a few items.
I was staring at the sliding head thinking of the "right thing to do"
and realised that the machine has interleaving of motion as well as
coordinated motion
While you could approximate that in the curre
19 matches
Mail list logo
