HAL configuration via GUI

[Daren Schwenke]

How about adding a simple graphical editor for configuring the HAL?  Before you freak out....

Pure Data is a real-time audio processing thingy I use, and has one written in Tk already. 

I see a lot of parallels between it and how Machinekit is laid out.

It covers a lot of similar concepts such as compiled modules, pins, signals, wiring, rules enforced on the wiring, real-time and user components, sliders, buttons, meters, little glowing thingys, etc all tied to the real-time engine.

All of it is encapsulated in a canvas, and canvas's are simply human readable (arguably) text files.

Sub-canvas can be created and translate into either inline or included files.  

Sub-canvases also have their own IO defined, so encapsulating a group of functionality is easy, and without hiding the inner workings for those who want to fiddle.

It is about as simple as something that complex can be made, and still has it's roots in text files.  Just a thought.

[Daren Schwenke]

If this sounds like a good idea, I have done some Tcl/Tk programming to facilitate it's creation. 

It was 10+ years ago, but I probably still know enough to put something together with a collaborator from the HAL side of things.

Objects in PD canvas's when sent to file end up being a list of strings of parameters, plus some X,Y coordinates for placement.  'Pins' on objects are numbered, and connections are done with 'connect' objects in the file, and show up as wires in the gui.  There are also signals, which are basically named connections and are mainly used to cleanup messy wiring, or add action at a distance stuff.  

So, my thought was with the correct implementation, the existing files could be used with the addition of a trailing comment containing the X,Y.  connect becomes net.

Loading un-converted HAL configs would simply result in all the objects at 0,0, and you could then drag them around to clean up.

[Daren Schwenke]

Well, in digging into the Pd source, the GUI logic for much of the useful stuff is actually implemented in C.

So, it won't be as easy as just pulling the tcl/tk bits.

On Wednesday, January 7, 2015 10:27:20 PM UTC-5, Daren Schwenke wrote:

[Alexander Rössler]

On Wednesday 07 January 2015 19:27:20 Daren Schwenke wrote:
> How about adding a simple graphical editor for configuring the HAL? Before
> you freak out....
>

> Pure Data <http://puredata.info/> is a real-time audio processing thingy I

> use, and has one written in Tk already.
> I see a lot of parallels between it and how Machinekit is laid out.
>

> <http://www.google.com/url?q=http%3A%2F%2Fplayground.arduino.cc%2Fuploads%2F
> Interfacing%2Farduino-test.pd.png&sa=D&sntz=1&usg=AFQjCNG4a8hcif9Z-DUV8NpSCU
> oO9HuvhQ>

>
> It covers a lot of similar concepts such as compiled modules, pins,
> signals, wiring, rules enforced on the wiring, real-time and user
> components, sliders, buttons, meters, little glowing thingys, etc all tied
> to the real-time engine.
> All of it is encapsulated in a canvas, and canvas's are simply human
> readable (arguably) text files.
> Sub-canvas can be created and translate into either inline or included
> files.
> Sub-canvases also have their own IO defined, so encapsulating a group of
> functionality is easy, and without hiding the inner workings for those who
> want to fiddle.
>
> It is about as simple as something that complex can be made, and still has
> it's roots in text files. Just a thought.

Shouldn't be that hard to implement. But what source does it use? Where does
it get the pins and parameters of each component? Does it use a running HAL
configuration to work on?

In fact the idea is good, but it should be as generic as possible.

Just viewing a running HAL configuration would be easier to implement.

[andy pugh]

On 8 January 2015 at 03:27, Daren Schwenke <darens...@gmail.com> wrote:

How about adding a simple graphical editor for configuring the HAL?

This is a great idea, but has been started and abandoned several times. 

http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Eagle2HAL

http://wiki.linuxcnc.org/cgi-bin/wiki.pl?HAL

http://wiki.linuxcnc.org/cgi-bin/wiki.pl?HalSchematicsUsingGschem

http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Rockhopper_Web_Server

The problem tends to be creating and maintaining a complete set of HAL component symbols. This is especially tricky with the Mesa cards which can have many hundreds of pins, and  they have pinouts that vary considerably depending on load-time parameters. 

The Rockhopper visualisation avoids this by only showing what actually exists, but that isn't as much help as one might wish for _developing_ a HAL configuration. 

--

atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

[Daren Schwenke]

Borrowing the grouping concept could help with that.  

Sub-canvases could hold the groups and only terminate the needed pins to the top level.  

If it's still messy, signals can do the same thing without wires from within the sub-canvas at the cost of readability.

Each component would need a mapping.  The up side is once you create the 'root' components that tie to the actual hardware, the method of abstraction and layout can be left to the user, re-grouped into other components, etc.

Like Pd, the existence of the component within the canvases could tell the hal to load it.  Multiple instances of the same component could be handled by requiring canvases to have unique names which makes sense anyway.

The parameters needed could be in-lined with the component name if short, or perhaps set as input to a 'startup' pin, the same way 'loadbangs' or 'bangs' in Pd send pre-configured or run time generated 'messages' to a pin.

[TJoseph Powderly]

Hope springs eternal,
i was one of many trying to use gui for hal

the problem i stumbled on was scope

that the detail you viewed disallowed seing the overall
and vsvs that viewing the overall miniturized the detail beyond recognition
( cant see the forest for the trees )

but lets avoid saying its impossible to begin with  ( positiev thoughts for 2015 folks!)

and i suggest that the 'page' metaphor of some elctrical schema systems be used (orcad etc)
by black boxing sub-units in hal, the overall can be seen, and the sub-schem can still be expanded/zoomed
this is because the overall view is simplified ( de-clutter-fied )
so an overall hal schematic is broken into sub-schematics, showing the major interconnects

recently i saw another candidate
http://gojs.net/latest/index.html

and heres a view of what can be done using the collapsing schematic idea
http://lmnts.lmnarchitects.com/interaction/grasshopper-canvas-meet-kinect/

BTW rhino/grasshopper can output gcode   and  rhino/grasshopper/firefly could gui talk to arduino/BBB

NB these projects are OLD
regards
TomP

[Bas de Bruijn]

On 08 Jan 2015, at 21:37, TJoseph Powderly <tjt...@gmail.com> wrote:

Hope springs eternal,
i was one of many trying to use gui for hal

the problem i stumbled on was scope

that the detail you viewed disallowed seing the overall
and vsvs that viewing the overall miniturized the detail beyond recognition
( cant see the forest for the trees )

but lets avoid saying its impossible to begin with  ( positiev thoughts for 2015 folks!)

and i suggest that the 'page' metaphor of some elctrical schema systems be used (orcad etc)
by black boxing sub-units in hal, the overall can be seen, and the sub-schem can still be expanded/zoomed
this is because the overall view is simplified ( de-clutter-fied )
so an overall hal schematic is broken into sub-schematics, showing the major interconnects

thinking about your mention of electrical schema’s,

wouldn’t a schema editor be easy to modify/hack so one could see if that works?

create not an IC but HAL-XOR2 and wire them to other components.

http://www.gpleda.org

http://wiki.geda-project.org/geda:gaf

these make also net lists for use in SPICE for example. Maybe tome tinkering would output pins to pins?

Bas

recently i saw another candidate
http://gojs.net/latest/index.html

and heres a view of what can be done using the collapsing schematic idea
http://lmnts.lmnarchitects.com/interaction/grasshopper-canvas-meet-kinect/

BTW rhino/grasshopper can output gcode   and  rhino/grasshopper/firefly could gui talk to arduino/BBB

NB these projects are OLD
regards
TomP

On Wednesday, January 7, 2015 at 9:27:20 PM UTC-6, Daren Schwenke wrote:

How about adding a simple graphical editor for configuring the HAL?  Before you freak out....

Pure Data is a real-time audio processing thingy I use, and has one written in Tk already. 

I see a lot of parallels between it and how Machinekit is laid out.

It covers a lot of similar concepts such as compiled modules, pins, signals, wiring, rules enforced on the wiring, real-time and user components, sliders, buttons, meters, little glowing thingys, etc all tied to the real-time engine.

All of it is encapsulated in a canvas, and canvas's are simply human readable (arguably) text files.

Sub-canvas can be created and translate into either inline or included files.  

Sub-canvases also have their own IO defined, so encapsulating a group of functionality is easy, and without hiding the inner workings for those who want to fiddle.

It is about as simple as something that complex can be made, and still has it's roots in text files.  Just a thought.

--
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.

[andy pugh]

On 8 January 2015 at 20:58, Bas de Bruijn <b...@basdebruijn.com> wrote:

thinking about your mention of electrical schema’s,

wouldn’t a schema editor be easy to modify/hack so one could see if that works?

If you look at my links, exactly that has already been done with Eagle2HAL and a similar thing for Geda/GAF. 

The schematic to HAL part is easy, the problem seems to be creating the "components" and keeping them up to date. 

I may be able to show you the graphical schematic I work with at work. It describes about 20% of the diesel engine ECU. I think I can safely show the front page publically as not a single text element is legible, even at max zoom. 

[Bas de Bruijn]

On 08 Jan 2015, at 22:07, andy pugh <bodg...@gmail.com> wrote:

On 8 January 2015 at 20:58, Bas de Bruijn <b...@basdebruijn.com> wrote:

thinking about your mention of electrical schema’s,

wouldn’t a schema editor be easy to modify/hack so one could see if that works?

If you look at my links, exactly that has already been done with Eagle2HAL and a similar thing for Geda/GAF. 

The schematic to HAL part is easy, the problem seems to be creating the "components" and keeping them up to date. 

I may be able to show you the graphical schematic I work with at work. It describes about 20% of the diesel engine ECU. I think I can safely show the front page publically as not a single text element is legible, even at max zoom. 

seeing the links you sent would make me think: how is that going to make better visualisation....

weeks ago when searching for dot visualisation i stumbled upon post of jepler, he wrote a python script to make dot output.

It’s not editable like GUI->HAL but at least it gives a wired view of the configuration, which pin to what other component pin

http://emergent.unpythonic.net/01174426278

[Alexander Rössler]

On Thursday 08 January 2015 21:07:24 andy pugh wrote:
> On 8 January 2015 at 20:58, Bas de Bruijn <b...@basdebruijn.com> wrote:
> > thinking about your mention of electrical schema’s,
> > wouldn’t a schema editor be easy to modify/hack so one could see if that
> > works?
>
> If you look at my links, exactly that has already been done with Eagle2HAL
> and a similar thing for Geda/GAF.
>
> The schematic to HAL part is easy, the problem seems to be creating the
> "components" and keeping them up to date.
>
> I may be able to show you the graphical schematic I work with at work. It
> describes about 20% of the diesel engine ECU. I think I can safely show the
> front page publically as not a single text element is legible, even at max
> zoom.

In fact it would be necessary to auto-generate the components. But I am not
convinced that a schematic editor makes creating HAL configurations easier.

Another question: What would the output of the schematic editor (or other
tool) look like? Halcmd code, Python code?

-
Alexander

[andy pugh]

On 9 January 2015 at 09:04, Alexander Rössler <mail.ar...@gmail.com> wrote:

> Another question: What would the output of the schematic editor (or other
> tool) look like? Halcmd code, Python code?

The output of Eagle2HAL is standard HAL-files, I believe.

https://github.com/ednisley/Eagle2HAL

[Charles Steinkuehler]

On 1/9/2015 3:04 AM, Alexander Rössler wrote:
> On Thursday 08 January 2015 21:07:24 andy pugh wrote:
>>
>> I may be able to show you the graphical schematic I work with at work. It
>> describes about 20% of the diesel engine ECU. I think I can safely show the
>> front page publically as not a single text element is legible, even at max
>> zoom.
> In fact it would be necessary to auto-generate the components. But I am not
> convinced that a schematic editor makes creating HAL configurations easier.

For me schematics would probably be harder to work with, but I'm
probably not a typical user.

I design hardware for a living, including circuit boards and complex
FPGA designs. Board level tools typically still use schematics, and
most of the tools available free for low end use (Eagle, KiCad, etc)
suffer from a serious lack of abstraction available. It's typically
difficult or impossible to reuse "chunks" of a design like a subroutine
(ie: create one amplifier or motor driver circuit and replicate it N
times), usually about the best you can do is divide the large design
into smaller chunks. This actually fits pretty well with the current
HAL file constraints, but it's not an elegant way to design large
complex systems.

For FPGA work, designs transitioned from schematic capture to VHDL or
Verilog (high-level hardware description languages) probably 15-20 years
ago. It is *MUCH* easier to create and maintain complicated designs
using VHDL than it is to have gigantic schematics like Andy is referring to.

Ultimately, I'm not sure how much newbie end users are really going to
have to be messing with HAL anyway. As someone mentioned previously, a
large chunk of current users fall into the "generated a HAL file with
stepconf and never looked at it" category. Also, I think the 3D printer
systems are substantially more similar than the array of retro-fitted
mills used with LinuxCNC, so assuming a suitable HAL file can be created
as an example, most folks will likely only have to tweak machine
specific limits in the INI file (or with a stepconf like utility). In
this case, I doesn't matter what the HAL file is written in.

As for Python, it might not be the perfect language for HAL, but it's a
very easy language for new programmers to use, and I don't think it will
scare off any of the Maker crowd currently pushing the limits of the
Ardunio and Cortex based controllers using embedded C.

--
Charles Steinkuehler
cha...@steinkuehler.net

[Daren Schwenke]

Ok.  Well if the general consensus is this won't make a difference then I have other fish to fry.

Perhaps a more concise collection of canned configs would serve the same purpose then.

I ended up being one of the people left behind, as I needed parallel + deltakins and so had to learn a whole lot about the HAL in short order to bring that to life.  

I'm a programmer, I love solving problems... but I didn't like that.

[andy pugh]

On 9 January 2015 at 16:38, Daren Schwenke <darens...@gmail.com> wrote:
> Ok. Well if the general consensus is this won't make a difference then I
> have other fish to fry.

I think that a schematic diagram feels like a very natural way to
design the HAL configuration.
However it has been started and not completed a number of times
previously, and the issue appears to be that it is only any good if
every HAL component is included in the library.

This might be hard to achieve, as it would require parsing not just
.comp files (relatively easy) but also some C-files that generate pin
names in their own ways, and the Hostmot2 driver which actually gets
the pin names directly from eeproms on the attached cards in some
cases.

So, to be useful the config util would have to load the drivers and
query HAL for the generated pin names. At that point it could be very
useful, but can onlybe used with a "live" system.

[Charles Steinkuehler]

Well I've done a lot of design with "black box" schematic components
where the guts were replaced by some non-schematic IP (typically
something like VHDL code or a library function of some sort). Most
packages have an option for exporting a netlist containing these "black
boxes" which could be used to support anything that didn't have a pretty
symbol already created in the HAL library.

I wonder if the problem isn't so much missing components but that anyone
who is comfortable making a schematic diagram of a HAL setup is also
comfortable just editing the HAL file directly?

I'm not trying to be sarcastic...I've been using schematic packages for
so long it's easier for me than driving a spreadsheet. I honestly don't
know how easy/hard it is for a new user to "grok" a text HAL file vs.
craft a HAL schematic. I suspect the biggest hurdle is being able to
logically put all the pieces together to create the desired HAL
structure (regardless of format). On top of that you add a conceptual
leap for representing the structure as either a standard HAL file or a
schematic.

I don't find HAL files so complex that I feel compelled to try and craft
them as a schematic. I'd rather take a bigger leap and switch to Python
or something and generate them programmatically. The "H" in VHDL is for
HAL, perhaps?!? :)

...but like I said, I suspect I'm an atypical user and probably
shouldn't be used as a reference.

--
Charles Steinkuehler
cha...@steinkuehler.net

[andy pugh]

On 9 January 2015 at 19:50, Charles Steinkuehler

<cha...@steinkuehler.net> wrote:
> ...but like I said, I suspect I'm an atypical user and probably
> shouldn't be used as a reference.

So am I, I suspect, but the other way.

The only programming languages I have ever been _paid_ to program in
are LabView and Simulink.

[John Prentice]

Greetings

I think I might lie in the middle of the "spectrum" - in a bar I might explain why and when I like LabView and text programming languages; but not now.

Please pardon a minor hi-jack. I find two things limit the transparency of HAL:

(a) The requirement to invent a name for every net (signal) and then visually ignore it when reading nets of the usual syntax with everything connected on one "line of code"

(b) The difficulty Andy refers to of "finding" the names of pins exposed by complex generic Components. 

To mitigate (a), jepler nearly took on board the suggestion to allow a "wild" net-name character that would autogenerate signal names but got sidetracked by something more interesting. After reading a few source files I have not had the courage to try attacking the HAL subsystem code.

For (b), enhancing the data associated/distributed with a Component, by a "template" file would allow a pin-suggesting editor/utility to be coded to help writing and checking HAL wiring. Perhaps this template could be like the XML that comes with a Mesa bitfile (or even a pseudo-bitfile header which has the maximum module configuration data and its pinout). halcompile (aka comp) could provide this file automatically. Naked C components would need it writing by hand. The hardest case would be comps whose personality provides inclusion and exclusion of some pins. With Hostmot it would be obvious, if one chose no PWMGENs, that these pins in the should not be wired even though in the template. In the case of something like bldc it might be confusing/misleading to many to be offered pins not in the personality to be used at runtime.

In summary anything that would declutter the HAL wiring and give a standard access to the documentation of pins names would help me a lot.

John Prentice

[Alexander Rössler]

On Friday 09 January 2015 17:36:08 andy pugh wrote:
> On 9 January 2015 at 16:38, Daren Schwenke <darens...@gmail.com> wrote:
> > Ok. Well if the general consensus is this won't make a difference then I
> > have other fish to fry.
>
> I think that a schematic diagram feels like a very natural way to
> design the HAL configuration.

Only for small projects. I think Charles is right. In the last 20 years chip
design moved from transistor level design with a schematic editor (or even
using a drafting machine!), to hardware description languages like VHDL and
Verilog and now slowly in the direction of system description languages like
SystemC.

A schematic editor may feel natural but its not very efficient for more
complex configs (I added a graphical representation of my 3D printer config).
We should focus on easier reusable configurations instead. Something like IP
cores in chip design.

The normal user will only tweak some parameters. This can be easier done in an
INI file than using HAL.

-
Alexander

[Bas de Bruijn]

ok, lets forget the “normal” user (if he exists :) because the normal user may not even like to tweak a HAL file. just plug and play.

say I’m not building a standard machine, but would like to make strange contraptions?

the future looks like it is going to go to more personalised goods, so I can imagine that also there it would have to be easy to make custom halfiles, where the configuration should easy understandable.

let’s forget for now that we have to see everything at once in one big view, be it Visual or Text

Would it not be good to see where a component is connected to? like filtering out all unnecessary components and only show the next neighbour or signal?

so what would it be like if 

• you only have 1 component 
• The pins that have connections with an arrow in/out/both to its neighbour/parent/child
• the unconnected pins in an easy accessible "layer below”

maybe a view where you see all components of the same kind filtered?

a view could also be done in text in the terminal, as well as visually with nodes and lines

Bas

-
Alexander

--
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.

<mymachine.png>

[Charles Steinkuehler]

On 1/10/2015 8:28 AM, Bas de Bruijn wrote:
>
> Would it not be good to see where a component is connected to? like
> filtering out all unnecessary components and only show the next
> neighbour or signal?

I like this idea.

The halcmd program already does a decent job of showing the
"interesting" bits if you give it a single component name. It seems
like crafting an interactive browser that would let you follow signal
paths would be pretty straight-forward to do with the python bindings
and could have a text or GUI front-end.

It's probably not unreasonable to have live updates as well, so you
could monitor the signal values while traversing the HAL "tree". Or
maybe right-click and throw up a halmeter/halscope type display for the
currently selected node. I think that could be very helpful for
debugging, and the code could be built up in pieces (starting with just
a python version of halcmd show).

--
Charles Steinkuehler
cha...@steinkuehler.net

[Bas de Bruijn]

I was just thinking about this when I was in the supermarket half an hour ago.

so you’d typically start the program

• choose to connect to a running realtime system, or open a HAL-configuration file.
• then you'd be able to work on this. 
• Suppose you opened a HAL-configuration. I would like to start the realtime system via this interface.
• If I connected to a realtime system, then I would like to be able to save that as a HAL-configuration file
• Removing/adding live connections on the fly (like switching signals and pins etc) and keep the name for reuse, like an unconnected labelled wire on the work bench. When you know which pin you want to connect it to you merge the dangling signal with the pin.
• seeing live values from the realtime system? yes please
• As a side, also making some sort of “test pin value”-file so you could use the HAL-logic with certain static input and as a result see the computed (static) value. A bit like a http://lighttable.com with some sort of inline evaluation of the logic

the big benefit would be that for simple applications, where you’d need a moving stepper motor, inputs, outputs, logic etc, but not necessary a full fledged system you could just use a hal-pin and use that as a start/stop button, and maybe some interaction with the setup. A bit PLC-like, with a state engine of sorts, inputs, states and actions in certain states.

It wouldn't be very hard parsing the manpages directories to make a useful library? We’d need that i think.

--
Charles Steinkuehler
cha...@steinkuehler.net

[jean-paul moniz]

Whatever is thought of, one should consider a average user (whatever that definition means).  From an acceptance stand point, anything done via text file configuration, will probably only be accepted by early adopters and those who live in the open source world. If the goal is to build an easier understanding configuration utility. Some GUI method is probably best.  PNC config filled has managed that gap in the past. If you look at the whole (MACH3 vs LCNC whats better argument). The pro MACH3 camp is usually driven by the fact that linux scares them and LCNC configuration is viewed as a higher degree of difficulty of understanding. Thus they migrate to what they view as the same but easier to use.  ( By no means am I implying they are the same)

I like the Idea of a type of graphical  Function block type of connect the dots type of GUI. I don't know how you couldn't get any straight forward than that. I am Biased as a PLC programmer. I prefer ladder but, I find function block programs are easy to read for a non programmer.

Just a thought

JP

[Bas de Bruijn]

On 10 Jan 2015, at 20:10, jean-paul moniz <jmo...@pmiautomation.com> wrote:

Whatever is thought of, one should consider a average user (whatever that definition means).  From an acceptance stand point, anything done via text file configuration, will probably only be accepted by early adopters and those who live in the open source world. If the goal is to build an easier understanding configuration utility. Some GUI method is probably best.  PNC config filled has managed that gap in the past. If you look at the whole (MACH3 vs LCNC whats better argument). The pro MACH3 camp is usually driven by the fact that linux scares them and LCNC configuration is viewed as a higher degree of difficulty of understanding. Thus they migrate to what they view as the same but easier to use.  ( By no means am I implying they are the same)

I like the Idea of a type of graphical  Function block type of connect the dots type of GUI. I don't know how you couldn't get any straight forward than that. I am Biased as a PLC programmer. I prefer ladder but, I find function block programs are easy to read for a non programmer.

Just a thought

Good thoughts!

TL;DR HAL file editing is in no way worthy of the year 2015.

Just a rant going on below. Apologies.

I’m very curious to our “average user” I think they are prepared to learn stuff, wether doing it via text or GUI doesn’t matter. it’s not the typing, its the “stupid typing”. They just don’t want to waste time (like me) doing stupid stuff like loosing focus, making typo's etcetera. The low hanging fruit could be to make a syntax-like situation with snippets and autofill/correct.

On that same line: They also don’t want to do “stupid clicking”. They are probably people with a good education or similar knowledge thru good and earnest experience.

I did some PLC programming on the Mitsubishi FX3U and Q series a few years ago so I know about the function blocks. And for all it’s simplicity and “crudeness” it works well. It just does what it needs to do.

maybe we need a component called “function block” in which we can make a diagram that does stuff, but we don’t want to see the details until we do.

Whether GUI or TUI, keeping focus on the component and what you intend to do, instead of seeing the entire configuration is mandatory for keeping it simple when you configure. One thing on people interested in configuring: They are not lazy couch potatoes, but engaged persons (probably spoiled and on their way to become drooling vegetables because of MS Word or very maybe LibreOffice Writer). Working with only typing characters in a text editor is just no fun, and error prone.

Like a HAL file now, I spend a lot of time looking for “where the hell is that sum2.4.in1 or was it in0 again”…. “oh, it’s 17 lines above”.

and then it’s only above because it fits just a little better in that part of the configuration instead of the current line. 

another example is that when you have a section like:

https://github.com/machinekit/machinekit/blob/master/configs/ARM/BeagleBone/BeBoPr-Bridge/velocity-extruding/lineardelta-vel-extr.hal#L334-L340

look at the last line:

net extruder-speed-adjusted sum2.2.out [PRUCONF](DRIVER).stepgen.03.velocity-cmd

I actually intended:

stepgen.03.velocity-cmd = mux4.0.out + lincurve.0.out

So I’m not particularly happy with a big HAL-file. I don’t hate signals per-se, but for the line above I had to write 3 lines, and loose overview. I’s not simple anymore. I want to be engaged with logic and controlling, not with signals. But hey, it’s all I have at the moment.

[Chris Morley]

 This sounds similar to halshow.
It shows  a treeview of HAL, you can select signals or pins or components.
You can set 'watching' of pins in a live system.
add a terminal window to it and it would be much handier..and re-coded it in somerhing besides tcl

Chris M

 

[Norbert Schechner]

And in all this we must take care that some pin must be connected postgui and others in certain order to work properly.

Imho the gui should look and feel like a elektical wire diagram.

Norbert

[jean-paul moniz]

Something like this would be handy. Just less cluttered obviously someone was being lazy. See attached

[Michael Haberler]

I feel there is a lot of enthusiasm for the HAL configure GUI idea

I do not want to spoil the party, but I do pose myself these questions:

- what is the relevant problem to solve? is it design? Is it inspection/debugging? documentation? ease of use?
- assuming it is design - is a GUI the right tool (beyond looking cool), and does it cover the hard part (like complex configs) adequately?
- is the complexity of ongoing HAL configuration jobs significantly reduced by such a tool, such that this benefit outweighs the implementation, documentation and learning effort of the tool per se? Or is it done because it 'looks doable'?
- will it be backed by a maintenance promise which is required to migrate users to a 'new, preferred way'? or will be a 'look Ma, no hands!' showoff which collects dust as soon as the Ooohs and Aaahs subside?
- instead of taking HAL as it is and slapping a design GUI on top - could the same manpower yield more bang, for instance by newer, simpler and more versatile _components_ (eg let's have many motion comps, for different purposes?)

I'd also suggest to review past efforts on the theme (which has come up about once or twice a year), the emc-users and emc-developers are worth a search

I also note that the HAL inspection tool almost every body uses now (Show HAL config in Axis) is based on TCL which does not have anybody around here able to fix, or extend (and at least in my case understand/read the code)


I guess what I'm saying is - there are easy, hard and relevant problems; unfortunately the intersection of 'easy' and 'relevant' is likely to be small

- Michael

[Charles Steinkuehler]

On 1/10/2015 6:21 PM, Michael Haberler wrote:
> I feel there is a lot of enthusiasm for the HAL configure GUI idea

Well, I work with schematics daily as part of my day job and don't feel
compelled to use a GUI or schematic-like HAL configurator.

<snip>

> I also note that the HAL inspection tool almost every body uses now
> (Show HAL config in Axis) is based on TCL which does not have anybody
> around here able to fix, or extend (and at least in my case
> understand/read the code)

Well, I can work my way through TCL (it's the automation language of
choice for SoC and FPGA designs), but IMHO converting to Python would be
worth the effort.

Also, I believe I was thinking too small with my earlier desires to use
INI include files and/or HAL constants. I think having a main HAL.py
file for a BeagleBone configuration will allow folding a lot of
functionality into one easier to maintain place, and probably improve
load times (which currently are pretty bad on a low-end platform like
the 'Bone). I'm thinking of the current setup.sh shell script which
checks for the presence of the proper device-tree overlays, sets up the
proper pin configurations, and other house-keeping. This could migrate
from shell script to a Python library/class (or whatever they call them
these days) and all you'd have to do is something like:

machinekit.beaglebone.cape_init(CRAMPS)

...and the hardware would be ready to go.

It should also be possible to launch "daemons" (like the temperature
reading code) directly from the main HAL.py file and background them,
although there should maybe be something that makes sure critical
processes are still running. Is there any current mechanism to have the
HAL code check that specific PIDs are still running? Should there be?

> I guess what I'm saying is - there are easy, hard and relevant
> problems; unfortunately the intersection of 'easy' and 'relevant' is
> likely to be small

Well, if it was easy, everyone would be doing it! ;-)

--
Charles Steinkuehler
cha...@steinkuehler.net

[Chris Morley]

On Saturday, January 10, 2015 at 4:21:24 PM UTC-8, Michael Haberler wrote:

I feel there is a lot of enthusiasm for the HAL configure GUI idea

I do not want to spoil the party, but I do pose myself these questions:

- what is the relevant problem to solve? is it design? Is it inspection/debugging? documentation? ease of use?

 

This is the right question and often missed.
It seems we are talking about two things here - Configuration and visualization.
Two related but different end games.
 

I'd also suggest to review past efforts on the theme (which has come up about once or twice a year), the emc-users and emc-developers are worth a search

This is also a good point.
 

I also note that the HAL inspection tool almost every body uses now (Show HAL config in Axis) is based on TCL which does not have anybody around here able to fix, or extend (and at least in my case understand/read the code)

Working on that would be a more useful endeavour I concur.  (IMHO)
Working on adding the bbb to stepconf would be very helpful too - I can't see a visualization configurer working or (if did) being easy for first time users.

I guess what I'm saying is - there are easy, hard and relevant problems; unfortunately the intersection of 'easy' and 'relevant' is likely to be small

- Michael

Chris M

[jean-paul moniz]

On Saturday, January 10, 2015 at 7:21:24 PM UTC-5, Michael Haberler wrote:

I feel there is a lot of enthusiasm for the HAL configure GUI idea

I do not want to spoil the party, but I do pose myself these questions:

- what is the relevant problem to solve? is it design? Is it inspection/debugging? documentation? ease of use?
- assuming it is design - is a GUI the right tool (beyond looking cool), and does it cover the hard part (like complex configs) adequately?
- is the complexity of ongoing HAL configuration jobs significantly reduced by such a tool, such that this benefit outweighs the implementation, documentation and learning effort of the tool per se? Or is it done because it 'looks doable'?
- will it be backed by a maintenance promise which is required to migrate users to a 'new, preferred way'? or will be a 'look Ma, no hands!' showoff which collects dust as soon as the Ooohs and Aaahs subside?
- instead of taking HAL as it is and slapping a design GUI on top - could the same manpower yield more bang, for instance by newer, simpler and more versatile _components_ (eg let's have many motion comps, for different purposes?)

The Example I posted was not in an attempt to say hey let's dumb things down. GUI's for HAL as pointed out by yourself and others have been discussed and stabbed at in many ways. When I said something like that would be cool it was with out context. If I look at what kind of benefits I and other system integrators could get out of a configuration like that, lots of ideas come to mind. Your point about what the goal would be is very correct. I viewed it as Configuration/Debugging. Think of this. One unified front end a user could go to accomplishing the following.

1. Create Hal Components  - things like User defined data types and User defined instructions.VIA GUI, comp or python. 

2. Create HAL Connections to setup a system.

3. View/Debug HAL connections in a live graphical view. 

4. View/Configure System Parameters.

5. Build Classic Ladder in?

I would think complex configs would be best suited with this approach and encourages creating modules/function block to compartmentalize things. As far as effort required, this "unicorn" GUI would obviously not be an easy task. If I decided to take something like that on, I'd be a year working on it perhaps even more.   

This is just my thoughts on what a HAL GUI "could be"  able to do if someone was to go down that road, or at least to to have those things in mind.

[Bas de Bruijn]

On 11 Jan 2015, at 01:21, Michael Haberler <mai...@mah.priv.at> wrote:

questions:

- what is the relevant problem to solve? is it design? Is it inspection/debugging? documentation? ease of use?

design + inspection/debugging + ease of use.

- assuming it is design - is a GUI the right tool (beyond looking cool), and does it cover the hard part (like complex configs) adequately?
- is the complexity of ongoing HAL configuration jobs significantly reduced by such a tool, such that this benefit outweighs the implementation, documentation and learning effort of the tool per se? Or is it done because it 'looks doable’?

making a HAL configuration from scratch is complex, and not for the guy/gal who just bought a BBB + a cape, bought a printer, installed the Machinekit package and only wants to start printing.

but I would like to design HAL configurations for machines I build which are new (think 6 DOF “linear stewart platform), or very simple like just 3 motors doing, 3 imputs and 10 outputs doing a simple “PLC” like job. Much more one-of-a-kind project specific machines.For that I’d likely start from scratch every time, instead of copy/paste/add to an existing configuration.

When I only think about how I would want to work, I don’t care about nice looking nodes or GUI per se. I’d want to make a good tool to make a HAL configuration. Could be low hanging fruit like an easier way of making the .hal text file. Maybe I haven’t dabbled enough with HALconfig and HALshow, but from the GUI you’d have to traverse the tree, look at pins, find other places to look, etc. etc. without a way (or I haven’t found one) to actually see how the configuration is intended configuration-wise.

- will it be backed by a maintenance promise which is required to migrate users to a 'new, preferred way'? or will be a 'look Ma, no hands!' showoff which collects dust as soon as the Ooohs and Aaahs subside?
- instead of taking HAL as it is and slapping a design GUI on top - could the same manpower yield more bang, for instance by newer, simpler and more versatile _components_ (eg let's have many motion comps, for different purposes?)

very good idea.

seeing the discussion about .INI vs .PY and modular configuring I’d have to tweak my opinion/thoughts regarding configuring HAL in the coming time.

[Michael Haberler]

> Am 11.01.2015 um 10:38 schrieb Bas de Bruijn <b...@basdebruijn.com>:
>
>
> On 11 Jan 2015, at 01:21, Michael Haberler <mai...@mah.priv.at> wrote:
>
>> questions:
>>
>> - what is the relevant problem to solve? is it design? Is it inspection/debugging? documentation? ease of use?
>
> design + inspection/debugging + ease of use.

and it should mix nice drinks, too ;)

>
>> - assuming it is design - is a GUI the right tool (beyond looking cool), and does it cover the hard part (like complex configs) adequately?
>> - is the complexity of ongoing HAL configuration jobs significantly reduced by such a tool, such that this benefit outweighs the implementation, documentation and learning effort of the tool per se? Or is it done because it 'looks doable’?
>
> making a HAL configuration from scratch is complex, and not for the guy/gal who just bought a BBB + a cape, bought a printer, installed the Machinekit package and only wants to start printing.
>
> but I would like to design HAL configurations for machines I build which are new (think 6 DOF “linear stewart platform), or very simple like just 3 motors doing, 3 imputs and 10 outputs doing a simple “PLC” like job. Much more one-of-a-kind project specific machines.For that I’d likely start from scratch every time, instead of copy/paste/add to an existing configuration.

well that is a good point, but let's look for a moment why we arrived at that situation

one could also take the view that the problem stems from poor support of modular composition - separating config data into namespaces and hierarchies which could more easily reused during assembly

note that HAL per se has no such concept, so any namespace separation has to come in 'above', and that is where INI as well as halcmd files provide zero help

assuming this - reuse - is the problem, then the design tool is probably not the solution

note - I'm not naysaying and doing 'told ya, warned ya', let's just drill down what the issue really is

>
> When I only think about how I would want to work, I don’t care about nice looking nodes or GUI per se. I’d want to make a good tool to make a HAL configuration. Could be low hanging fruit like an easier way of making the .hal text file. Maybe I haven’t dabbled enough with HALconfig and HALshow, but from the GUI you’d have to traverse the tree, look at pins, find other places to look, etc. etc. without a way (or I haven’t found one) to actually see how the configuration is intended configuration-wise.
>
>> - will it be backed by a maintenance promise which is required to migrate users to a 'new, preferred way'? or will be a 'look Ma, no hands!' showoff which collects dust as soon as the Ooohs and Aaahs subside?
>> - instead of taking HAL as it is and slapping a design GUI on top - could the same manpower yield more bang, for instance by newer, simpler and more versatile _components_ (eg let's have many motion comps, for different purposes?)
>
> very good idea.
> seeing the discussion about .INI vs .PY and modular configuring I’d have to tweak my opinion/thoughts regarding configuring HAL in the coming time.

that was the point - issues like namespace separation, module import, persistence, and string processing are bread+butter for Python, and an eternal source of warts if one insists on INI being 'simpler' - unfortunately only for the trivial case, the not-so-trivial becoming next to impossible without ongoing guru help with yet another heroic patch (includes, environment variables etc come to my mind)

- Michael

[Bas de Bruijn]

I’m starting a new thread because I’m curious about smarter HAL motion components:

Michael mentioned  the following in this thread

On 11 Jan 2015, at 11:28, Michael Haberler wrote:

- instead of taking HAL as it is and slapping a design GUI on top - could the same manpower yield more bang, for instance by newer, simpler and more versatile _components_ (eg let's have many motion comps, for different purposes?)

I searched a little bit but could not find anything on the following:

multiple instances of a kinematics module

I can imagine that I want 3 1-DOF movements

which is not

1 3-DOF movement.

So I’d like to do something like this:

```

loadrt lineardeltakins

loadrt gantrykins

loadrt 1DOFkins names=infeed-belt,removal-belt

```

then i’d like the infeed-belt and the removal-belt to be able to make point to point movement

• with acceleration and deceleration settings etc. having nothing to do with the cartesian motion planning from the lineardeltakins or gantrykins for example
• maybe running on a lower thread since it’s just a simple 1 axis non-critical motion
• So each kinematics is doing its own task.

one thing that can happen is that both kinematics can come in the same volume. So maybe a “collision-volume” component should exist, with pins that stop/error certain kinematics the moment they are in the same space.

Remember: 1 fool can ask more than 10 wise men can answer :)

Bas

[Andrew K]

2015-01-08 5:27 GMT+02:00 Daren Schwenke:

How about adding a simple graphical editor for configuring the HAL?  Before you freak out....

 

That's a great idea. Though I don't feel like using a large graph to configure HAL, it might be useful to check connections etc.

I guess that everybody experienced with LinuxCNC knows his way through configuring the machine. Though editing HAL and INI could be more convenient for us too, it often becomes a stumbling block for newcomers. Stepconf or pncconf makes a config, but understanding it or adding something requires too much effort for a novice. 

 Though INI's more simple, but for a novice it looks scary too. What's least comfortable about editing HAL? For me it's a constant scrolling up and down looking for a signals/pins names, copying them, adding components at the top and then going down to use them. Which is constantly interrupted by looking to the manual. So, how do we make it easier, more comfortable, and a lot faster? 

What I'm suggesting is basically a LinuxCNC IDE. Not sure if someone already suggested this... anyways:

Let's start from INI as the first to describe the machine, and easier target. INI editor is probably pretty obvious. 

Say, it could look like UPG https://www.dropbox.com/s/7xnbqqd5h8rw6xw/2015-01-11%2016.52.37.png?dl=0 (which by the way also produces a text file similar to INI).

Choosing "New machine" or "Open a machine" pops a window with tabs corresponding to INI sections DISPLAY, TRAJ and all of them.

Each tab has a complete set of all possible parameters for the current section with corresponding radio buttons, checkboxes, numerical fields etc.

AXIS_n sections could be sub-tabs in AXES tab. Which has "Add axis" and "Delete axis" buttons adding a tab, each AXIS_n tab has a switch stepper/servo. The axis is created with default properties which need to be checked/unchecked or values corrected. Then there's "Copy axis" and we have all the nesessary tabs an a few clicks.

And so on, and so on...

Very important point: each button, checkbox or edit field has a bubble help with the manual snippet describing this parameter. So no need to constantly search through the manual.

This makes editing INI file clear and transparent even for a novice who never saw Linux. And more advanced people could use it instead of INI manual, eventually.

Now, editor particularly made for HAL. First it loads INI file and (optionally) generates the corresponding template with basic components and connections.

"Add component" menu includes (at least most popular) components with their descriptions. Which adds loadrt and addf strings at once. When the component already exists it adds "count=2".

It also has a menu with a typical blocks: servo axis, stepper axis, spindle, toolchanger. Each section can be reduced to a line/unrolled.

Pointing at each component shows its description and list of pins. Pointing to a signal shows connected pins. "Connect to..." might be useful for pins and signals.

INI and HAL editors could be integrated, stepconf/pncconf might become wisards in LinuxCNC IDE.

I know this is a lot of work, but it could be valuable for both novice and pro.

-- 

Andrew

[andy pugh]

On 11 January 2015 at 15:40, Bas de Bruijn <b...@basdebruijn.com> wrote:
> then i’d like the infeed-belt and the removal-belt to be able to make point
> to point movement
>
> with acceleration and deceleration settings etc. having nothing to do with
> the cartesian motion planning from the lineardeltakins or gantrykins for
> example

"limit3" already does exactly this. Also (for reasons I don't actually
understand) Stepgen has its own accel and velocity limits, so that too
can perform point-to-point motions simply by feeding it targets.

[andy pugh]

On 10 January 2015 at 14:09, Alexander Rössler <mail.ar...@gmail.com> wrote:
> A schematic editor may feel natural but its not very efficient for more
> complex configs (I added a graphical representation of my 3D printer config).

Off topic, but the engine control software I work with is almost
entirely defined and written as block diagrams (annoyingly in an
mixture of Simulink and ASCET depending on the supplier)

The documentation I get given is 6000 pages of such diagrams. But it
is easier to follow the intent of those sections than it is the
sections written in C.

[Bas de Bruijn]

On 11 Jan 2015, at 20:54, andy pugh <bodg...@gmail.com> wrote:

> On 10 January 2015 at 14:09, Alexander Rössler <mail.ar...@gmail.com> wrote:
>> A schematic editor may feel natural but its not very efficient for more
>> complex configs (I added a graphical representation of my 3D printer config).
>
> Off topic, but the engine control software I work with is almost
> entirely defined and written as block diagrams (annoyingly in an
> mixture of Simulink and ASCET depending on the supplier)
>
> The documentation I get given is 6000 pages of such diagrams. But it
> is easier to follow the intent of those sections than it is the
> sections written in C.

I did a google search on "open source graphical blocks library”
why not for example have both, like the picture on page 23 of this pdf.
http://dspace.mit.edu/bitstream/handle/1721.1/41550/220927290.pdf

>
> --
> atp
> If you can't fix it, you don't own it.
> http://www.ifixit.com/Manifesto
>

[andy pugh]

On 11 January 2015 at 20:08, Bas de Bruijn <b...@basdebruijn.com> wrote:
> http://dspace.mit.edu/bitstream/handle/1721.1/41550/220927290.pdf

Turtle TNG in that paper seems to combine the worst of both worlds,
being effectively a text-based procedural language forced into a
graphical framework.

I think that the block paradigm works well for data processing (and
that is what HAL is). LabVIEW is a reasonably good example, where
(conceptually) each block "executes" only once all the inputs get new
data.
One advantage of a GUI for HAL is that it could automate the correct
sequence of the addf statements.

This is an image of some LabVIEW code, actually quite a good example
as it is very close to a HAL type of thing:

http://www.computer-solutions.co.uk/gendev/images/Example_LABview_diagram.png

I don't find Simulink as clear:
http://www.mathworks.com/matlabcentral/fileexchange/screenshots/6926/original.jpg

But to answer Michael's questions, I don't know if a GUI solves a
problem that needs solving. And it would be a lot of work to find out,
and it has been tried and abandoned many times before.

[TJoseph Powderly]

I do not aspire to writing a gui configurator
I lowered my expectations (SNL) and tried to write a tool to help explain Hal files.

Hal files are not structured like VHDL or C
they are a mess
look at the supplied examples.
try to communicate the idea of a hal file to another person
only by talking to them, no knapkins allowed

Why graphical explainations?
because they are human.
can you imagine a map of Tokyo in text? no lines?
could you imagine a text only web?
try a text only browser for a day

look at the explanations of how the Linuxcnc code is organized
its in pictures!
why?
because the code is a mess. ( great code, no offense guys!)
but
"you have entered a maze of twisty little passages..."

The textural code map is not as good as the graphical code map

I really dont think this is just my opinion,

How I got into the hal gui maelstrom...
I began with the earliest THC implementations
Dallur et al
and have a square meter printout of the supplied diagram.
it's a mess too,
but an easier to understand mess than the hal file.

so, i suggest diagrams as a way to study and explain hal files

tomp
tjtr33

[Bas de Bruijn]

> On 11 Jan 2015, at 22:10, TJoseph Powderly <tjt...@gmail.com> wrote:
>
> so, i suggest diagrams as a way to study and explain hal files

Exactly. The old saying goes: a picture says more than a 1000 words (or did they mean 8?)
Viewing something doesn't mean you'd have to throw the keyboard (which I certainly appreciate) out of the window.

Bas

[Daren Schwenke]

I propose we do both.

ini work:

Generate functional blocks of reusable code.  Put each one in it's own file.

Load them as includes.  

Define ins and outs in some standard way so not every net gets exported by default.

Gui work:

Generate a gui where each included file becomes a functional block, parsing top down from the main ini file.

Functional blocks are expandable.  Components appear as function blocks as well.  

Most will be encapsulated within other functional blocks, cutting the clutter at the top level.

Functional blocks are available to drag from a left panel into a right panel.  

The left panel is just a folder view of the includes, and a folder of components.

The right panel is the main ini file.

Dragging adds an include.

net connections become wires.  

Ins are always left/top.  Outs are always right/bottom

Two problems I see right off the bat:

I don't believe includes can include other includes.  (perhaps python to the rescue?)

I don't believe you can connect a net to a net.

[Marius Alksnys]

I support HAL GUI idea very much.

Have you seen Grasshopper UI (Rhinoceros plugin)? I think it is great.

I also know it was programmed in C#, not very friendly to Linux, but maybe it is possible to adapt somehow, or at least borrow main GUI ideas..

More info:

http://en.wikipedia.org/wiki/Grasshopper_3D

www.grasshopper3d.com

[TJoseph Powderly]

Marius,
this is several years old,
but I been watching rhino grasshopper & firefly
a video shows a beatiful zooomable panable ui
http://lmnts.lmnarchitects.com/interaction/grasshopper-canvas-meet-kinect/
tomp
(drool)

[Daren Schwenke]

I goofed around with this last weekend.  I started with the flowchart example from here:

http://www.pyqtgraph.org/

Zoomable, panable, connections with in/out enforcement out of the box.  I didn't get anything accomplished besides trying to take it apart to remove the stuff I didn't need.

[Bas de Bruijn]

> On 11 Jan 2015, at 20:37, andy pugh <bodg...@gmail.com> wrote:
>
>> On 11 January 2015 at 15:40, Bas de Bruijn <b...@basdebruijn.com> wrote:
>> then i’d like the infeed-belt and the removal-belt to be able to make point
>> to point movement
>>
>> with acceleration and deceleration settings etc. having nothing to do with
>> the cartesian motion planning from the lineardeltakins or gantrykins for
>> example
>
> "limit3" already does exactly this. Also (for reasons I don't actually
> understand) Stepgen has its own accel and velocity limits, so that too
> can perform point-to-point motions simply by feeding it targets.

OK, that's already there then.
But what about loading more than 1 kinematics?

And are something like collision-monitoring-components something usable with smarter motion components?

>
>
> --
> atp
> If you can't fix it, you don't own it.
> http://www.ifixit.com/Manifesto
>

[Bas de Bruijn]

> On 11 Jan 2015, at 20:37, andy pugh <bodg...@gmail.com> wrote:
>

> "limit3" already does exactly this. Also (for reasons I don't actually
> understand) Stepgen has its own accel and velocity limits, so that too
> can perform point-to-point motions simply by feeding it targets.

But I'm wondering if you'd get the other functionality like homing, homing offsets etc with them.

[andy pugh]

On 15 January 2015 at 06:55, Bas de Bruijn <b...@basdebruijn.com> wrote:
> But I'm wondering if you'd get the other functionality like homing, homing offsets etc with them.

No, that isn't there. You could set up a baroque structure of
sample-hold components and offset components, and then wcomps to
report following error.
There might be something to be said for rolling it all in to one component.

[Bas de Bruijn]

> On 15 Jan 2015, at 07:52, Bas de Bruijn <b...@basdebruijn.com> wrote:
>
> But what about loading more than 1 kinematics?

Nobody even curious to loading 2 kinematics for a machine? No smart motion collision components?

[Charles Steinkuehler]

I'm very interested in something like this, just busy with other things
right now. :)

There's no fundamental reason you can't have the kinematics for multiple
joint systems that have possibly overlapping ranges in HAL at the same
time (although today you can't do something as simple as load an AND2
gate HAL component more than once, but that can be worked around if
neecessary). In addition, currently there's no easy way to control a
setup like this (the trajectory planner and motion queue tend to assume
there's only one thing being controlled), but I think HAL and haltalk
should be flexible enough to allow this if/when anyone decides they want
this bad enough to start writing code.

--
Charles Steinkuehler
cha...@steinkuehler.net

[Bas de Bruijn]

On 16 Jan 2015, at 23:39, Ralph Stirling <Ralph.S...@wallawalla.edu> wrote:
> Yes! I want multiple instances of kins, motion, interpreter, so I can build mfg assembly systems with several 3+ axis manipulators without a rack full of pc's. Even a 2 spindle lathe with two turrets would need it.
>
> — Ralph

On 17 Jan 2015, at 05:17, Charles Steinkuehler <cha...@steinkuehler.net> wrote:
>
> I'm very interested in something like this, just busy with other things
> right now. :)
>
> There's no fundamental reason you can't have the kinematics for multiple
> joint systems that have possibly overlapping ranges in HAL at the same
> time (although today you can't do something as simple as load an AND2
> gate HAL component more than once, but that can be worked around if
> neecessary). In addition, currently there's no easy way to control a
> setup like this (the trajectory planner and motion queue tend to assume
> there's only one thing being controlled), but I think HAL and haltalk
> should be flexible enough to allow this if/when anyone decides they want
> this bad enough to start writing code.
>
> --
> Charles Steinkuehler

I’m glad I’m not the only one :)
I Imagine that you’d have to have 2 instances of the motion to do that, each separate from each other.
I was thinking the other day about being able to insert a cam-curve-component (kinematics probably) apart from an x-y-z movement of other kinematics.

Bas