PnCConf rework

arvidb wrote:

cmorley wrote:

Now I can do these calculations, but I doubt very much if most people even realise that it is possible to calculate this value. And I also think that most people have a hard time even guessing a reasonable acceleration value in this context. And add cutting forces and it really gets impossible to enter a sane value.

As I see it, the kinematics module should have functions to calculate the maximum acceleration and speed at a specified cartesian coordinate, and the trajectory planner should ask the kinetics module about this while planning the tool path. The input to the kinematics module would be max joint torque, rpm, and other data (masses, arm lengths etc depending on the type of kinematics).

The way we get around this is to have a testing / tuning option.
Also getting a ballpark setting is really not that hard, 200 inches per minute on a Sherline isn't gonna work long, or all you have to do is ask on the forum.
I would bet most people find the velocity units pretty intuitive, acceleration not so much.
In fact with PNCconf I changed the velocity units to per minute because few people use per second in the machinist world.

Chris M

arvidb wrote:

My plan is to allow all combinations of cards that fit physically together, and display a note to the user that "Make sure your mesa FPGA cards have the correct firmware to support your daughter card setup.", or something like that. At least that's a start.

Well what I was trying to say is if you are going to figure out the pin number of the daughterboard (using the standard way) you must know which serial channel the user has connected it to. While some cards like the 5i25/7i76 combo is easy (there is only one user available) other cards can have many.

If you are going to use the new method then I guess you just need to keep track of where the card was connected - I really haven't figured out how that live interrogation would work as far as mapping pinnames.

Chris M

arvidb

I like the concept for the setup utility your building! I wish more linux software was written in a straight forward logical way.
As far as the Axis / Joint debate - IMHO most users are building / retrofitting a "normal" mill type machine or lathe where there are only 3 - 5 "axes" If someone wants to build a hexapod or terminator or something - it's probably going to be beyond the scope of a "configurator" and they can always use it as a starting point for modification to the hal files anyway. ie: It might make your quest easier to cater to the 90+% instead of "trying to be all things to all people"

Maybe OT but, if someone can come up with a script that would install / copy the required firmware / setup files to the proper directories
(and hopefully your completed program - at some point) as well as perhaps a forum directory for all the latest firmware / configs so that us newbs could be a little more self sufficient, that would be awesome. Please let me know if I can help in some way - I only know enough scripting to be dangerous, but I'm willing to learn more & help with the effort.

Just my 2c

Thanks for the encouragement!

I've had no time to work on it this weekend. Hopefully next weekend will be better.

I totally agree about the "cater to 90+% instead of being everything to everyone". But even for a normal mill type machine I think that it might be useful to make the joint/axis distinction, because even on such a machine there _is_ a difference between an axis and a joint (such as the maximum speed on multi-joint movements). And even if you build a normal type of machine, you still might want to use gantrykins, or millkins (for skew correction), which makes the distinction useful (from an educational/awareness point of view, if nothing else).

I hope that if this configurator turns out to be useful, it will end up in master and be installed by default eventually.

Had some time to work on this again this weekend. I've been able to put the "proof of concept" pieces that I had together, so now I can build a hardware hierarchy, switch to the next screen and configure output/feedback/limit/home of the joints, and get "kind of" a hal file. Still need to work on the hal pin names there.

Another major thing on the TODO list is a machine config page where one can set machine name, units, etc.

Still, it's moving forward!

Still working on this??

Beta coming soon maybe?

Yes, I'm still working on this, and ... well, not a "Beta" perhaps (in the sense that it is a fully featured program that should be tested for bugs), but some code that can be used to build a hardware tree, configure joints and then produce the joint ("axis") parts of a .hal file should be coming soon.

I don't have much time for this unfortunately; I've only been able to work a few hours each weekend the last weeks. But there is some progress nonetheless!

Between work and the coming of spring this hasn't got a lot of attention from me. This week though, I had a terrible cold, and I was so bored lying feverish in the sofa that I picked up pen and paper and figured out the last small missing links for getting the hal names right in the configurator.

An hour of programming today and it seems to work. I think it's time to present the code for those interested.

What does it do?

It allows the user to select a hierarchy of Mesa cards (out of a few of the existing models) and to configure Control, Feedback and Limit/Home inputs for nine joints, using the facilities of the selected cards. It then generates a partial .hal file (named example.hal), with nets and parameters for joints 0-2.

It does this in a way that should make it relatively easy to add new types of cards and to maintain the code. (To see what's needed for a new card, look at the M7I77 class in hardware/mesa_fpga.py - see if you can add the M7I76 for fun! )

I have also tried to make it friendly for new users who have no prior knowledge of HAL and other specifics of LinuxCNC.


What doesn't it do?

Everything else, i.e. INI file creation, .hal file header, cartesian config, open loop test, etc., etc.

IT'S NOT BY ANY MEANS READY FOR END-USER USE! So please don't try to report bugs. I also do not know when it will be "finished".


My TODO list at the moment:

* HW layout screen: Custom TreeStore
* HW layout screen: Show connectors in tree (i.e. "P3: 7I77", "P2: <not connected>")
* HW layout screen: Pretty-print card names
* HW layout screen: HW sel box gray when "Computer" re-selected?
* HW layout screen: Conn sel box should empty on unselect?
* HW layout screen: Support for Sserial cards

* Joint config screen: Show qualified Terminal names when several cards are available

* Machine page w/ joint selection, naming etc.

* INI file writing

* Axis/cartesian configuration...


How do I try this out?

Unpack the archive, cd tmb-0.1/, run ./lcncconf.py. Select the cards you want to add to the tree to the right. I.e.: Select a 5I25 card and press Add. This adds the card to the tree to the right and also selects the newly added card in the tree. Select a 7I77 card and press add again.

Press Next to go to the Joint config page. Select one of the joints with the tabs on the top (or use the default Joint 0). Configure Control, Feedback, overtravel and/or Home (the input fields to the right are not yet used). Make sure to switch away from the last configured tab to "record" the changes.

Press Next to generate the example.hal file.

Press Ctrl-C at the terminal to quit.





If you want to study the code, please read the doc/classes.txt file first.