Different behavior of Linuxcnc 2.7.14 on stretch compared to Wheezy

OK so in this case, something like hardware_drivers.hal with two pass disabled
would be a solution. (stiil curious about what has changed)

At some point I would like to try to make up a sample hal file setup with all the hardware specific bits confined to a hardware.hal file that makes all the hardware setup and net connections of the hardware specific pins to generic signals, leaving the structural part of the hal file hardware independent.

Hi pcw
I did that for 7i76e and it works for the inputs. But not for the outputs.
Hat to comment them out, leaved them for documentation, and have them in according hal.

It's a pitty that this kind of issue is not testable in simulation. Even a stub hostmot2/hm2_pci would still need _some_ intelligence to complain e.g. in a case in which it is loaded wrongly / without considering the dependencies.

Anyway, then it's back to wheezy for me...

Regards,
Daniel

Mike_Eitel wrote:

Hi pcw
I did that for 7i76e and it works for the inputs. But not for the outputs.
Hat to comment them out, leaved them for documentation, and have them in according hal.

What was the error?

Possibly the hardware/structure parts would need to be further spilt into source/destination

mydani wrote:

It's a pitty that this kind of issue is not testable in simulation. Even a stub hostmot2/hm2_pci would still need _some_ intelligence to complain e.g. in a case in which it is loaded wrongly / without considering the dependencies.

Anyway, then it's back to wheezy for me...

Regards,
Daniel

What about dgarrett's suggestion? This was advised back on 2.5 and its may not be a
great idea to use two pass processing for complicated config lines at all...

Due to the issue with the M6 remap not working at all,w/o errors but also not executing any M/G commands in the corresponding .NGC file - abort/debug commands are executed though.
With an unchanged machine config I would have expected same behavior.

The remap error is possibly a library error also

My point only about TWOPASS and is that its already suggested in the documentation
that you do not use TWOPASS for complicated loadrt lines.

Yeah, got it - already implemented this one - no more twopass for me.

Did you try the Stretch test ISO?
I would think a remap bug would have been caught there

Hi pcw
To be honest, I can't remember in detail, but:

I use TWOPASS and call my 7i76e.hal as the first hal.
I net the inputs to signal = NET Signal <= input
I tied the same with signals for output= NET Signal => output

It works OK with the inputs but I could not use it with output. Either I believe i got errors on the line where the output was used first time.
My idea is to have the HW in done kind of abstraction hal, do you could easy swap the card-type without changing the app. Also much easier to document pins to cabling....
Mike
P. S. Master 2.8, ca 4 month agoo.