Thanks for fast reponse. Yes I understood that linuxcnc accepts G-code input, drives CNC machines in response, means directly drives the axis/stepper motors.

My hope was that there is also a mode to drive the axis via RS232.
The LinuxCNC-DNC software ( github.com/mizoguch-ken/LinuxCNC-DNC )
sounds like it would support the DNC Languag (my IMC4 is using), may be I missunderstood and its the way arround, that it supports an input via serial interface (instead of G-Code), but I'm not really sure because could'd find a documentation.

If I understand your answer correctly (I'm not a native speaker) it says using linuxCNC would even make no sense for my use-case because than I would have 2 CNC controllers in a que?

Because I need G-Code support may be the best solution would be to get rid of my IMC4 controller and build up a new hardware which is supported by linuxCNC (only reuse the mechanics and motors, but this is high effort), or does somebody know a G-Code to ISEL DNC-Code converter?

Hallo Leute,

Ich habe in den letzten 2 Wochen meine Portalfräse mit einer neuen, sauberen LinuxCNC-Installation incl. Probe Basic versehen.
Die 3 Achsen laufen hervorragend auf JMC Closed Loop iHSS60-36-30-21-38.
Als Steuerungskarte lief eine MESA 7i96s.

Nun wollte ich die Genauigkeit nochmals verbessern und habe meine Achsen mit Magnet-Linear Encodern versehen.
Zur Signalverarbeitung kam eine 7i85s dazu und die 7i96s wurde mit der entsprechenden Firmware geflasht.
Nach etwas testen und Jumper setzen, erhalte ich nun auf allen 3 Achsen saubere Signale über die ersten 3 Encoder-Eingänge der 7i85s.

Soweit so gut. 
Nun zum Problem.
Ich habe die HAL nun testweise nur mal für die X-Achse entsprechend angepasst.
Sobald ich nun die Maschine aktiviere beginnt die X-Achse selbstständig, sich ganz langsam sich aufzuschaukeln bis sie in einen Positionsfehler fällt. Nun habe gibt es 2 Optionen.

1. ich bin zu blöd die Pins in der HAL korrekt zu verbinden (was durchaus möglich ist)
2. Der Closed Loop versucht ständig zu korrigieren und der Messwert (PID) arbeitet dagegen.

Ich komme hier irgendwie nicht wirklich weiter.
Könnt Ihr mir hier bitte helfen.

Hier mal die HAL und INI (wie gesagt, ich habe erst mal nur X zum Test umgestellt)
 
 

Vielen Dank und viele Grüße
Jens
   

Hi,

Yes, that's why I asked about active development, should have mentioned that post If I manage to make something useful, does it matter if the code uses Python API or is written in C? 

Tero

I think the problem is solved.
Thanks a lot.

Best regards 

Unless you have an added parallel daughtercard, it's unlikely you need
to change the installed firmware.

Since you are using pncconf that does not directly support the 7I95/7I95T
the list of pin names is useful since in has the names of the isolated inputs
like:

hm2_7i95.0.inmux.00.input-00

and isolated outputs like:

hm2_7i95.0.ssr.00.out-00

are there.

If you do not want to add these by hand to a pncconf created configuration
you could use mesact instead of pncconf, since mesact supports the 7I95/7i95T
directly

This is very helpful but I don't understand. It appears you are using two pins. I have my Emergency Stop switch attached to GPIO25. It is designated as INPUT. I get errors when I try to add the second line [net estop-ext => [HMOT](CARD0).7i84.1.1.output-08} with references to -output.  I don't see a need for output in an eStop unless it is to communicate with software. With what I understand, I did this:

I created an input on GPIO25 -
loadrt hal_gpio inputs=GPIO7,GPIO8,GPIO25,GPIO12,GPIO13
I created an input:
net estop-ext <= hal_gpio.GPIO25-in
Then I used one of your suggestions:
net estop-ext => iocontrol.0.emc-enable-in
And so now, when I press my eStop (which at present is non-latching) the program momentarily stops. If I release it, it restarts (bad).
I think I am missing the second part- not allowing the machine to come on after the button was pressed.

Part of failing is what you learn along the way. I know of "a rule" that eStops should be Normally Closed. Yesterday, that is all I knew. Today however, I am well-versed in ISO 13850:2015 Safety of Machinery - Emergency stop functions - Principles for design. Today I have a strong opinion that you are right! The reality is my schematic I'm using from Byte2Bot does it otherwise, so shall I.
But we divert! I don't see any GPIO25's in this banter.

OK got the file but it tells me a whole lot of nothing i understand.

From what i understand so far is that there are bin files that are pre configured for the board.
Like in the second Picture attached.
In the first picture are what seems to me are such files which are provided by mesa.
Which basicly does nothing for me because i cant look into them or research which does what.

Trying my best to understand and get a hang of things.
 

Also are those things correct for your steppers, they look big to me.

Are you dropping packets? that is, what is:

hm2_7i76e.0.packet-error-total

A dropped packet will result in a (bogus) following error spike,
as stale stepgen position (from the previous cycle) will be compared
with the commanded position. At a 2 ms servo thread period and 125 mm/sec
velocity, a .25 mm reported following error value is possible from a dropped
packet. Note the this does not mean that there is an actual path deviation
of this magnitude, this is bounded by the max_error PID pin to ~.0127 mm
per dropped packet.

I still think the physical error is most likely mechanical as it only shows up on Y.

To diagnose stepgen errors, the best thing is to plot the following error
with halscope like this:

 


Note that this is in inches, but the velocity and acceleration are about 4x and 6X your machines values
and the inherent stepgen error is less than  0.25 micron.

Another possibility if the system latency is really bad, is loss of DPLL sync, so you might try increasing
the DPLL time from -250 to -500 usec