Advanced Search

You don't seem to have "addf"ed the lowpass and abs to the servo thread.
(See the other components in the HAL file for examples)

It looks like nobody has exactly what you want. What type of toolchanger is it?

scsmith1451 wrote:

Upon restart the following error was spit out:

ERROR: function 'abs.spindle' not found

Checking the HAL file it appears to be caused by this line:

addf abs.spindle servo-thread


 

Du kannst Teile deines M6 Remaps durch Abfragen des '_task' Parameters vom Preview und somit von der Limitüberprüfung ausnehmen:

What is the exact error?

For direction, assuming S1 is FWD and S2 is REV:

S1 --> OUT4A 
OUT4B --> COM

S2 --> OUT5A 
OUT5B --> COM
 

Sorry habe eine Frage gestellt und mich lang nicht mehr gemeldet. Da kam was privates dazwischen und somit musste Linuxcnc warten.
Vieleicht erkläre ich nochmals etwas anders was meine eigentliche Frage ist. Außerdem habe ich nicht alles gesagt was wichtig ist. Ist mir aber beim ersten Schreiben nicht aufgefallen.Ich habe den M6 geremappt (schreibt man das so?) Ich habe die Dynamische Werkzeug-Längenvermessung von Talla83 eingebaut. Diese funktioniert auch.Kurz der Ablauf:
Man legt ein beliebiges Werkzeug ein
Man startet einen Toolwechsel  z. B. T2 M6
Anschließend nullt man das Werkzeug auf die Oberfläche
Beim nächsten Werkzeugwechsel wird der Tooloffset TLO wieder so berechnet das die Spitze des Werkzeugs auf der Oberfläche aufliegtMein Problem ist nun das der Werkzeugwechsel mit in die Berechnung der Grenzwerte mit einbezogen wird. Das hätte ich gerne ausgenommen. Mir ist schon klar dass wenn ich ein super kurzes Werkzeug nehme das ich dann die Z-Achse evtl nicht mehr tief genug fahren kann und umgekehrt wenn ich ein besonders langes Werkzeug nehme  dann evtl die Z-Aches nicht hoch genug fahren kann. Aber ganz ohne mitdenken geht es beim fräsen ohnehin nicht.Nun 2 Beispiele. Ich würde gerne eine Berechnug wie in Beispiel 1 haben auch wenn wein Werkzeugwechsel vorkommt.Beispiel 1Starte ich ein Fräsprogramm bei dem beim Start bereits das passende Werkzeug in der Spindel ist, dann beschränkt sich die Berechnung der Grenzwerte sozusagen an der äußeren Kontur des Objetes. Beispiel: Ich fräse ein Quadat mit einer Kantenlänge von 10mm welches mit der linken unteren Ecke auf X0, Y0 Z0 liegt  mit einem 4mm Fräser aus. Dann sind die Grenzwerte in X -2 und X12, gleiches in Y.
Liegt die eingestellte Sicherheitshöhe bei 15mm und die Frästiefe bei -2mm sind die Grenzwerte in Z-Richtung Z-2mm und Z15mm.

Beispiel 2Habe ich aber noch kein passendes Werkzeug in der Spindel, werden die Wege zu dem Platz an dem ich das Werkezug wechsle bzw an dem das Werkzeug vermesse mit beachtet. So ist z. B. X plötzlich -450mm. Bei den Z-Werten passt gar nichts mehr, die sind meist außerhalb Bauraum. Ich vermute das liegt daran das LCNC bei den Befehlen die antasten (G38.2) nicht weiß wie weit sie wirklich fahren.

Wenn man davon ausgeht das der Befehl T2 M6 wenn man ihn in der Befehlszeile ( MDI) eingibt an sich funktioniert und nie den Bauraum verläßt, sollte er doch eigentlich nicht dazu führen können, wenn er in einem Fräsprogramm auftaucht, dass dann die Z-Achse die Grenzwerte überschreitet.Die LCNC-Version ist 2.93Anbei ein Bild wenn bereits das richtige Tool vorhanden ist und ein Bild wenn noch ein anderes Tool geladen ist.Und die Routine die die dynamischen Werkzeugwechsel macht.

In my process to integrate the X/Y crosshair laser into my test machine configuration, searching the forum I read that gladevcp had a toggle button that sounded like it would work for controlling the laser on/off. Modifying my configuration with pncconf I replace my pyvcp with gladevcp using the default sample with just the spindle speed bar and spindle at speed LED.

Starting LCNC the machine an error was generated indicating that the n_rows property for the gladevcp was not valid. A little more forum searching if found the GTKbugfix.tar.gz archive and following the forum guidance copied the files to their correct location.

Upon restart of LCNC, the gladevcp panel displayed correctly. Excited, I decided to include the sample's Zero X/Y/Z/A buttons via pncconf.

Upon restart the following error was spit out:

ERROR: function 'abs.spindle' not found

Checking the HAL file it appears to be caused by this line:

addf abs.spindle servo-thread

Figuring that this was somehow connected with adding the ZERO buttons, I removed the buttons via pncconf and restarted.

Now LCNC generates the error every time it is started.

I'm befuddled and do not know where to go from here. Anyone have any ideas?

Kind Regards

Yes, I think that there's a misunderstanding of how differential signaling works here.

The high input sensitivity allows detection of small differential signals but the differential noise
immunity is equal to the differential signal level from the source.  Because it is a differential
receiver designed for a high noise environment, it has a wide common mode range (-7 to +12V)
meaning it can detect small differential signals (> 200 mv) accurately even with -7 to +12V of
common mode noise. This is why RS-422 signaling is used for encoders.

If the 7I76 single ended setting works better than the differential setting on supposedly
differential signals it suggests that there is some hardware issue.

I would check first that you have true differential signals from the encoder.

To do this, use a voltmeter across the differential pairs (A,/A B,/B IDX,/IDX)
and measure the voltage as you jog the encoder a bit to get both states.

One state should read a positive voltage and the other a negative voltage.
in no case should the absolute differential voltage be less than 2V.
 

Hallo zusammen
Ich habe einige Probleme mit dem Teil. in Simulations modus startet das Ding nicht und in normalen Modus habe ich keinen Kontakt. Der Treiber startet , hatt aber einen Konflikt mit GLADE-Dateien

Starting HAL User Interface program: halui
linuxcnc TPMOD=tpmod HOMEMOD=homemod EMCMOT=motmod
Found file(REL): ./core_sim.hal
Found file(REL): ./spindle_sim.hal
Found file(REL): ./simulated_home.hal
Found file(REL): ./whb04b.hal
Shutting down and cleaning up LinuxCNC...
Removing HAL_LIB, RTAPI, and Real Time OS modules
Removing NML shared memory segments

Debug file information:
Note: Using POSIX realtime

failed to claim interface
scale: already exists
./whb04b.hal:20: waitpid failed /usr/bin/rtapi_app scale
./whb04b.hal:20: /usr/bin/rtapi_app exited without becoming ready
./whb04b.hal:20: insmod for scale failed, returned -1
13130
Stopping realtime threads
Unloading hal components
Note: Using POSIX realtime


 
 

Das whb.pendant.is-connected sollte doch gelb aufleuchten, oder ?

What power supply is powering the drive?
2 years back i had some really bad power supplies that caused a lot of noise, so i did the humane thing and showed them the trash bin.

I'm sorry I don't understand what the point of checking to see if #_task> is equal to 0 in my sub program that is intended to end the program.  And maybe that isn't the best way to do that.  I basically have two branches, the surfacing program can end either at the front or back of the machine depending on where it runs out of space.  Then it needs to raise the spindles, turn them off, and end the program.  Maybe it would have been better to end it like this.

Yes, that is correct.

Axis GUI?
Did you accidentally press the 0 on the keyboard? That would set the feed rate to 0 and would do exactly as you describe, namely start and go to the first cut and stop there waiting.

I will try that tommorrow , There is no real Identification on the PC, Small Black Box , Has a Motherboard and a Hard drive only.