PnCConf rework

cmorley wrote:

Looking pretty good.

Thanks!

cmorley wrote:

I would name it something snappy like: machine builder.

Hmm... "The Machine Builder". Sounds cool.

cmorley wrote:

In your hardware tree how will you select which connector the 7i77 is on? If there are optional sserial boards how will you select which sserial channels they are on?
Will you allow deselection of components to free up GPIO?
Forgive me if I am getting ahead of you - I understand WIP.

I'm not sure I understand the first question. You have seen the big combobox labeled "Connector" in the first picture, right? This page needs lots of polishing; it was the first one I made and it doesn't look good. One thing is that the connector that a card is connected to should be displayed, something like "P3:7I77" instead of just "7I77" under the 5I25.

Sserial channels: each daughter card knows how many sserial channel it consumes. Each FPGA card knows what type of daughter card is supported on each port. Therefore it should be possible to figure out the channel numbers. At least, that's my hope.

Deselection of components/GPIO: First: I'm not sure how this works. Say I have a 7I77x2 firmware, which means 6 encoders are supported, but I only enable 3. Will the encoders on the 5I25 P2 connector then automatically turn into GPIOs?

Second: Is this a feature that is commonly used? Or does it just complicate matters for newbies?

Any way, I do have an idea on how to add this functionality in case it is needed.

And if there is a time to ask these questions, it is now (and not when the program is "finished", if such a state exist for software ). So I welcome them!

cmorley wrote:

One thing I always wanted was to have sane defaults for imperial and metric units. PNCconf just converts the imperial units and it doesn't always make sense. Something to keep in mind.
Even nicer if you could switch units per page - sometimes metric units are used on an other wise imperial machine.

Hmm, I'm wondering if it would be worth the trouble to create "unit aware" entry boxes. I.e. use only metric base units internally and let the entry boxes/labels do the correct conversions... could be useful especially when talking about acceleration and such convoluted units. With these one could also designate a single default value and use the conversion factor 25.0 to get inch default values, to make them look less weird. (But of course use the correct 25.4 for non-default conversions). Lots of work though...

cmorley wrote:

I like the single signal / pin per line - nice and clean.

I especially like the grouping of nets. It was surprisingly educational to see where a signal comes from and where it ends up.

cmorley wrote:

I would add a checkbox to invert the index direction and latch style.

and on a linear axis max velocity is usually shown in mm/min

Axis velocity, yes, but these are joint settings. I guess one would typically want to enter the mechanical limits here. And instead of max acceleration, the sane quantity to enter would be max torque, but that doesn't really help since LinuxCNC wants a maxium acceleration value, and we do not know the rotational inertia of the machine joint being configured... Who wrote the trajectory planner? There's work to be done!

This was my thinking when I wrote RPM in the unit label. Will probably change it back to <units>/min so as not to complicate matters too much.

andypugh wrote:

This would be a good time to switch to identifying sserial boards by serial number, rather than attached port.

However, this may not help if the configurator doesn't poll hardware to interrogate the boards.

How do you envision this working? Aren't many boards both sserial and "direct", i.e. 7I77 has got encoder inputs directly connected to the FPGA card, but IO via sserial (I think). What happens if I move such cards around?

What happens when a card has been moved and an old configuration is loaded into the configurator The Machine Builder?

andypugh wrote:

One thing I always wanted was to have sane defaults for imperial and metric units. PNCconf just converts the imperial units

Off topic, but I saw a great example of this the other day "The temperature rose by 2 C (36 F) through the day"

Hehe

The serial number scheme begins to look nice when you have multiple sserial expansion cards (its fairly common on big machines to have more than 100 inputs) This may take three 48 bit sserial input cards. With the current pathname scheme if you accidentally swap two serial cables to the same type of sserial remotes, LinuxCNC will load and "work" but the inputs will be all wrong. If serial numbers are used, everything will just work.

I'm not sure I understand the first question. You have seen the big combobox labeled "Connector" in the first picture, right? This page needs lots of polishing; it was the first one I made and it doesn't look good. One thing is that the connector that a card is connected to should be displayed, something like "P3:7I77" instead of just "7I77" under the 5I25.

Yes I looked at the tree view.

Sserial channels: each daughter card knows how many sserial channel it consumes. Each FPGA card knows what type of daughter card is supported on each port. Therefore it should be possible to figure out the channel numbers. At least, that's my hope.

Your thinking 5i25 and it's daughter cards. Yes it is fairly easy to figure out what goes where.
Other cards can have multiple sserial channels that can support many different daughter cards.
The FPGA knows nothing about what daughter boards is supported. you can glean info from the firmware name or Peter says he will build daughtercard hints.

Deselection of components/GPIO: First: I'm not sure how this works. Say I have a 7I77x2 firmware, which means 6 encoders are supported, but I only enable 3. Will the encoders on the 5I25 P2 connector then automatically turn into GPIOs?

Second: Is this a feature that is commonly used? Or does it just complicate matters for newbies?

yes that's roughly how it works.
I think it's important in some form. eg 7i77x2 is a common firmware for the 5i25. If you only have one 7i77 daughter card (I would assume common) then if you can't deselect components then you can't use half of the 5i25. for hi speed GPIO.
lots of firmware for the mainboards are 'dual' setups like this.

Axis velocity, yes, but these are joint settings

well in 95% of configs (my estimate) it's axis velocity. Until linuxcnc fully separates the ideas (will be a long time I bet) no use forcing the concept.
Nobody is going to just know the motor RPM for a particular speed.
most will understand inches per minute or mm per minute.

Chris M

PCW, andypugh:

I can see that serial numbers can be very useful in many circumstances.

But I also see the situation where a "part sserial, part direct" daughter card is moved. Suddenly some parts of the card work, while others doesn't. Much better that *nothing* works, which lets you draw the conclusion that "oh, I moved the card, perhaps that's the problem".

So the ideal situation perhaps would be to use serial numbers for remote serial daughtercards (the purely sserial ones), and keep the old scheme for "hybrid" cards like the 7i77/7i76? Is this possible?

andypugh wrote:

arvidb wrote:

Deselection of components/GPIO: First: I'm not sure how this works. Say I have a 7I77x2 firmware, which means 6 encoders are supported, but I only enable 3. Will the encoders on the 5I25 P2 connector then automatically turn into GPIOs?
Second: Is this a feature that is commonly used?.

Yes, very much so.
Many firmwares allocate every pin, but people often connect one encoder/pwm card and one IO card. disabling the encoders/pwm on the IO card connector.

Hmm, are you talking about IO cards like the 7I42? I didn't realise that they don't require specific firmware support.

It should be no problem supporting these.

cmorley wrote:

Sserial channels: each daughter card knows how many sserial channel it consumes. Each FPGA card knows what type of daughter card is supported on each port. Therefore it should be possible to figure out the channel numbers. At least, that's my hope.

Your thinking 5i25 and it's daughter cards. Yes it is fairly easy to figure out what goes where.
Other cards can have multiple sserial channels that can support many different daughter cards.
The FPGA knows nothing about what daughter boards is supported. you can glean info from the firmware name or Peter says he will build daughtercard hints.

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.

cmorley wrote:

Axis velocity, yes, but these are joint settings

well in 95% of configs (my estimate) it's axis velocity. Until linuxcnc fully separates the ideas (will be a long time I bet) no use forcing the concept.
Nobody is going to just know the motor RPM for a particular speed.
most will understand inches per minute or mm per minute.

I agree that there is no use forcing the concept at the moment.

But for the sake of discussion:

As I understand these settings (MAX_VELOCITY and MAX_ACCELERATION under the [AXIS_n] section), my guess is that they are used by the trajectory planner's path control (G64) to ensure that no steps are lost (steppers) or that servo overspeed/overtorque are not triggered (servos). (Infinite acceleration would be optimal for perfect tool path following and cycle times. Ufortunately the reality of physics sets limits...)

The settings under [TRAJ] are then used to set comfortable maximum limits for acceleration and speed for any cartesian move, independent of which joints are involved (except that physical joint limits may force further reduction of these values).


To take a real world example, I will have to calculate backwards to get suitable (speed & acceleration) values for my machine:

Speed: my servos can do 3000 RPM, and with 4:3 belt reduction and 5 mm/turn screws the maximum joint speed becomes 11250 mm/min, which is what I enter.

Acceleration: This is limited by motor torque (0.64 Nm for my servos). To be able to enter an informed linear acceleration value (and not just guess), one would have to do this:

1) Calculate the linear force delivered by the screw when turned at maximum torque: F = M*ŋ*2*pi/s, where M is torque, ŋ is screw efficiency, s is screw lead. With 4:3 reduction and a ball screw of ŋ = 0.9, F = 965 N in my case.

2) Subtract static friction from this value.

3) Convert the rotational inertia of the screw to a "linear inertia" (mass). This is a bit involved and I won't get into it here.

4) Add the value from step 2 to the mass of the table/carriage being moved.

5) Use Newton's law to calculate the achievable acceleration: a = F/m.

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