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
> coordinated motion
>
> While you could approximate that in the current system with effort in
> perhaps a special cam software system
> it would be better if it became built in somehow
>
> The way it currently works is a camshaft rotates once per part this
> drives cams for all slides, collets
> and accessory movement.
>
> this means while turning a dia another tool can be on a fast move
> into/out of position ready to start/finish cutting
> one tool could be cutting a dia while another cutting a taper
>
> That type of machine was "programmed" as starting/finishing an
> operation/move at an angle(time/number or revs of the total operation)
> of the cam
> just have to avoid crashes :)
>
> The machine also has mechanical gain(ratio) and offset so a class of
> parts can be made without remaking cams
> this also helps adjust tool wear/settings during production.
>
> I have seen other mentions on the list of machines that have multiple
> milling heads, I think this is the same problem
> normally the answer has been run multiple pcs and coordinate, this
> would be wrong on a single spindle sliding head lathe
>
> I found a working example on youtube
> http://www.youtube.com/watch?v=TDxvBHXklJo
>
> The rocker has two tools one being the cutting off tool so you can see
> the cycle time achievable with the method.
> shame about the flood lubricant and shaky camera work.
>
> Found a brochure for a later version on a forum
> http://www.practicalmachinist.com/vb/general/bechler-10-lathe-243337/
>
> There have been a number of machines where a lot of axes are the same
> but just hold a different tool like this, there is a need to address
> their multiple axes in a consistent manner my machine has 4 X axes and
> a Z, not counting anything mounted on the front accessory block
>
> I have a couple of accessories one has three drills that can be
> brought into line with the spindle and the other has saws (screw head
> production probably)
>
> Dave Caroline
I'm currently gathering what could be LinuxCNC3 requirements, and see how that
can be folded into a plan and a time axis. Anyway.
(what is actually the proper term for such a setup? multiple-spindle might be a
bit narrow in focus)
from the above I derive:
- assuming Linuxcnc runs on single machine:
Some key components which are currently singletons must become fully
instantiable.
These are: task, the interpreter embedded in task, the motion module, and the
motion/task interface; iocontrol as long as it exists in its current form (this
is a minimum list; probably I forgot some). Usrmotif probably could be coerced
into supporting multiple motion instances, but the motion module per se isnt
there AFAICT.
Other than motion, most of the HAL components are instantiable multiple times
(any other troubling exceptions?)
As long as all instances live in a single memory space, HAL could be used to
synchronize instances; a bit low-level but workable
- assuming LinuxCNC, or at least the RT control part, runs on separate machines:
then synchronization will have to move to messaging, and that will be whatever
replaces NML (btw methodically syncing be message exchange is a lot easier to
get right than in a shared memory model).
In both cases, synchronization will happen in or near HAL, but must be
represented as language constructs at the RS274NGC level, and probably task has
to involved to synchronize multiple interpreters ("forking" and "joining" of
"Gcode threads", omigawd); this could be fudged with Python oword procedures as
a stopgap measure.
And then, a UI or multiple UI's which can deal with it. That's all..
---
related: one of the drawbacks of the current architecture - which I'd like to
remove in LinuxCNC3 - is:
while within HAL one can create and link pretty much arbitrary component
instances as needed, this is not the case for modules which take command
messages, and deliver response messages (message meaning 'a compound of more
than one HAL signal, to be interpreted by a given module atomically once it
gets around to it'). Actually the plural is nonsense, there's only the motion
module which can do this.
The consequence: motion sucks in ALL functionality and code which necessarily
relies on messaging to/from task - motion control proper, spindle
on/fwd/rev/orient support, homing..) since there is no way to split and
interface HAL components as soon as they interface by messaging; this only
works with pins and signals. We currently cannot do a separate spindle, or
spindle orient, or homing component, and have them more easily replaceable than
code currently within motion. And consequently no one ever ventured to do
another message-based component (probably fended off by weighing the motion
code ;)
Enabling this would in essence mean "layering" of message-based components: for
instance, "homing" could generate feed move commands, and motion picks them up
and executes them. Or "spindle orient" could pretty much run in isolation,
except for synchronizing with feed-hold.
To support this, what is now the task/motion interface needs to be abstracted
and generalized so multiple components 'can have one' without jumping hoops,
and the scheduling of commands needs a bit more thought; I (currently) think it
is relatively straightforward to do by creating a generic interface of this per
module command/response message interface and hook it into the scheduling layer
which will be exclusively message-based to start with.
--
these are early thoughts in the paper scribblings stage; next thing is to
validate this with a Python mockup - a few threads (representing HALcomps with
messaging) which communicate through ZeroMQ sockets. When that looks feasible,
the necessary HAL adaptations can be derived.
- 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
------------------------------------------------------------------------------
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
