Powtran FU Ansteuerung (Modbus) mit LinuxCNC

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Powtran FU Ansteuerung (Modbus) mit LinuxCNC

      Hallo zusammen :)

      Ich habe einen Powtran FU, welchen ich gerne mit Linux CNC über den Modbus (RS485) ansteuern möchte.
      Es ist aber leider nicht ganz so einfach, das hinzukriegen...

      Auf der Suche im Web bin ich dann auf diesen Beitrag bei euch hier gestossen:
      FU von Sourcetronic - ST9100A 2,2Kw

      Dort steht dass es mit dem Huanyang einfach so funktioniert, und bei dem Powtran mit der mb2hal Komponente funktionieren müsste.

      Ich verstehe aber leider das mit der mb2hal noch nicht ganz. Wie muss ich hier was einbinden? Funktioniert dass dann einfach so, oder was muss ich wo noch anpassen?
      Kann mir das vielleicht hier jemand erklären, wie ich das genau machen muss?

      Freundliche Grüsse und vielen Dank!!

      Michi


      Edit vom 11.7.2019:

      Es funktioniert nun alles wie gewünscht! :thumbup:
      Im letzten Thread hier sind die funktionierenden Dateien zur Kommunikation zwischen LinuxCNC und dem POWTRAN FU zu finden ...

      The post was edited 1 time, last by sutter.michi ().

    • Hallo.

      "Einfach so" funktioniert das wahrscheinlich nicht. Ich kann nur spekulieren, da ich keinen Powertran FU habe, sondern einen Parker AC10.

      Ein grundlegendes Problem beim AC10 ist, dass er nur den Befehl zum Schreiben eines einzelnen Register kann (fnct_06_write_single_register) und mb2hal nur den Befehl zum Schreiben von mehreren Registern in einem Rutsch (fnct_16_write_multiple_registers).

      Daher habe ich einen Patch geschrieben, der mb2hal den nötigen Befehl beibringt. Der ist zwar in die Entwicklungsversion von LinuxCNC aufgenommen worden, aber es gab seit dem keine neue stabile Version. D.h. man muss sich das leider selber kompilieren.

      Ich habe mein Vorgehen unter wiki.linuxcnc.org/cgi-bin/wiki.pl?VFD_Parker_AC10 dokumentiert. Ich denke, dass das mit einem Powertran FU ähnlich funktionieren sollte. Man muss halt nur die zu ändernen Register anpassen und schauen, ob die Berechnung von Drehzahl in Frequenz dort auch notwendig ist, oder ob man dem Powertran FU evtl. direkt die Drehzahl per ModBus schicken kann.

      Selber kompilieren ist jetzt auch kein Hexenwerk, aber wenn man das noch nie gemacht hat, evtl. schon etwas erschlagend. Wenn man nicht selber kompilieren will, dann muss man halt auf die nächste LinuxCNC-Version warten.

      Bei der Konfiguration von HAL und MB2HAL kann evtl. jemand konkreter weiterhelfen, der den gleichen FU hat. Ansonsten kannst Du meine AC10-Sachen als Grundlage nehmen und das mit dem Handbuch des Powertran entsprechend anpassen. Falls Du das machst, wäre es bestimmt sinnvoll, das auch im LinuxCNC-Wiki zu veröffentlichen, damit der nächste sich da nicht auch durchkämpfen muss.

      Tschüss,
      Lars
    • Hi Lars.

      Kann ich irgendwo nachlesen/ rausfinden wie ich was genau kompilieren muss oder könntest du mir das erklären?

      Ich muss die komplette LinuxCNC Distribution kompilieren oder nur den Teil für die mb2hal?

      Ist nach der Kompilation diese Komponente dann schon drin oder funktioniert das erst überhaupt mit dieser kompilierten Version?

      Ich habe noch nicht ganz verstanden was eine neue Kompilation mit der hal zu tun hat ...

      Gruss

      Michi
    • Hallo Michi.

      sutter.michi wrote:

      Kann ich irgendwo nachlesen/ rausfinden wie ich was genau kompilieren muss oder könntest du mir das erklären?

      linuxcnc.org/docs/master/html/code/building-linuxcnc.html

      Wobei ich da gerage gesehen habe, dass es einen Buildbot für LinuxCNC gibt. D.h. Du kannst Dir fertig kompilierte Versionen runterladen. Im 2.7er-Zweig ist der benötigte Patch noch nicht enthalten, d.h. Du brauchst mindestens den 2.8er-Zweig. Die Pakete gibt es dazu hier:

      buildbot.linuxcnc.org/dists/
      Ich muss die komplette LinuxCNC Distribution kompilieren oder nur den Teil für die mb2hal?
      Prinzipiell sollte die mb2hal-Binary reichen. D.h. Du könntest versuchen usr/bin/mb2hal aus dem Debian-Paket über Dein /usr/bin/mb2hal zu kopieren. Am besten vorher mb2hal aus dem Paket irgendwo hin zu kopieren und mit Argument "--version" ein Mal versuchen zu starten. Wenn es da einen Fehler bzgl. fehlender dynamischer Bibliotheken gibt, dann musst Du das 2.8er Debian-Paket komplett installieren. Ansonsten sollte es so laufen, denke ich.
      Ist nach der Kompilation diese Komponente dann schon drin oder funktioniert das erst überhaupt mit dieser kompilierten Version?
      Die Frage verstehe ich nicht.
      Ich habe noch nicht ganz verstanden was eine neue Kompilation mit der hal zu tun hat ...
      mb2hal vermittelt zwischen HAL und Modbus. Dein FU kann nur mit einem Modbus-Befehl beschrieben werden, den mb2hal in der aktuellen 2.7er-Version nicht unterstützt. Mit dieser mb2hal-Version kannst Du den FU nur auslesen. Das ist wahrscheinlich nicht sonderlich hilfreich. Daher brauchst Du eine neuere Version von mb2hal, um den FU auch steuern zu können.

      Für zukünftige Fragen wäre es hilfreich, wenn Du mehr Details liefern würdest. Du hast nicht geschrieben, was Du gemacht hast, was Du für eine Version benutzt, RTpreemt, RTAI oder sonst irgendwelche Infomationen.
      Wie man LinuxCNC kompiliert kann man z.B. auch mit 5 Sekunden Google-Magie herausfinden.

      Ich kann Dir hier keine fertige Anleitung liefern. Ich habe die Powertran FU nicht und so wirst Du nicht umhin kommen selber die Anleitung und die Konfigurationsdatei durchlesen, verstehen und selber anpassen zu müssen.
      Ich habe meine Dateien für den Parker AC10 ins LinuxCNC-Wiki gestellt. Das sollte ein guter Startpunkt sein.

      Bei konkreten Fragen kann ich gerne versuchen zu helfen, aber ohne Details ist das halt schwierig bis unmöglich.

      Tschüss,
      Lars
    • chaotix wrote:

      Prinzipiell sollte die mb2hal-Binary reichen. D.h. Du könntest versuchen usr/bin/mb2hal aus dem Debian-Paket über Dein /usr/bin/mb2hal zu kopieren. Am besten vorher mb2hal aus dem Paket irgendwo hin zu kopieren und mit Argument "--version" ein Mal versuchen zu starten. Wenn es da einen Fehler bzgl. fehlender dynamischer Bibliotheken gibt, dann musst Du das 2.8er Debian-Paket komplett installieren. Ansonsten sollte es so laufen, denke ich.
      Okay, das wollte ich grade probieren.

      Kann ich denn diese einzelne neue MB2HAL Datei irgendwie auslesen/ runterladen. Oder muss ich die ganze Distribution herunterladen und installieren?
      Falls ja, habe ich das Netz zwar durforstet, aber mir ist noch immer nicht klar wie ich mit diesem Buildbot die neuste Linux Version auf meinen PC bekomme.

      Mache ich das im bestehenden LinuxCNC auf meinem Fräsen-PC selber mit diesen Paketinstallationen? Aber wenn er mir hier dann drüberinstalliert dann sind ja die alten Sachen weg.

      Oder kann/ muss ich das ähnlich wie hier die ISO Linux Datei herunterladen und dann auf dem PC installieren?


      Irgendwie stehe ich noch auf dem Schlauch und finde keine passenden Antworten...
      Über Tipps oder einen Link wie das mit dem Buildbot genau funktioniert, wäre ich recht dankbar!


      Gruss

      Michi

      PS.:

      chaotix wrote:

      Für zukünftige Fragen wäre es hilfreich, wenn Du mehr Details liefern würdest. Du hast nicht geschrieben, was Du gemacht hast, was Du für eine Version benutzt, RTpreemt, RTAI oder sonst irgendwelche Infomationen.

      Aktuell installierte Version von Linux und Linux CNC:

      Linux Version 3.4.9-rtai-686-pae (Debian 3.4.55-4linuxcnc) () (gcc version 4.6.3) (Debian 4.6.3-14)
      Linux-CNC: 2.7.0

      The post was edited 2 times, last by sutter.michi ().

    • Hallo.

      sutter.michi wrote:

      Kann ich denn diese einzelne neue MB2HAL Datei irgendwie auslesen/ runterladen. Oder muss ich die ganze Distribution herunterladen und installieren?
      Weder noch. :)

      Wenn Du LinuxCNC über ein ISO installierst, dann ist da zu 99% ein "normales" Linux. Es sind nur ein paar LinuxCNC und Realtime-spezifische Pakete mit dabei. Wenn Du also was aktualisieren wolltest, dann würdest Du einfach die Pakete vom Buildbot darüber installieren.

      Aber das wollen wir ja gar nicht machen. Du brauchst ja nur eine Datei.

      So kann man das z.B. in einem Terminal machen:

      Source Code

      1. lars@cnc:~$ cd /tmp/
      2. lars@cnc:/tmp$ wget http://buildbot.linuxcnc.org/dists/wheezy/2.8-rt/binary-i386/linuxcnc_2.8.0~pre1.4839.gc378f1e_i386.deb
      3. --2019-06-21 12:38:09-- http://buildbot.linuxcnc.org/dists/wheezy/2.8-rt/binary-i386/linuxcnc_2.8.0~pre1.4839.gc378f1e_i386.deb
      4. Auflösen des Hostnamen »buildbot.linuxcnc.org (buildbot.linuxcnc.org)«... 174.16.203.136
      5. Verbindungsaufbau zu buildbot.linuxcnc.org (buildbot.linuxcnc.org)|174.16.203.136|:80... verbunden.
      6. HTTP-Anforderung gesendet, warte auf Antwort... 200 OK
      7. Länge: 14734570 (14M) [application/x-debian-package]
      8. In »»linuxcnc_2.8.0~pre1.4839.gc378f1e_i386.deb«« speichern.
      9. 100%[===============================================================================================>] 14.734.570 617K/s in 24s
      10. 2019-06-21 12:38:34 (605 KB/s) - »»linuxcnc_2.8.0~pre1.4839.gc378f1e_i386.deb«« gespeichert [14734570/14734570]
      11. lars@cnc:/tmp$ dpkg -x linuxcnc_2.8.0~pre1.4839.gc378f1e_i386.deb temp
      12. lars@cnc:/tmp$ ldd temp/usr/bin/mb2hal
      13. linux-gate.so.1 => (0xb77ac000)
      14. liblinuxcnchal.so.0 => /usr/lib/liblinuxcnchal.so.0 (0xb7788000)
      15. liblinuxcncini.so.0 => /usr/lib/liblinuxcncini.so.0 (0xb7784000)
      16. libpthread.so.0 => /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 (0xb776a000)
      17. libglib-2.0.so.0 => /lib/i386-linux-gnu/libglib-2.0.so.0 (0xb766d000)
      18. libmodbus.so.5 => /usr/lib/libmodbus.so.5 (0xb7662000)
      19. libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xb74fa000)
      20. libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb740e000)
      21. libm.so.6 => /lib/i386-linux-gnu/i686/cmov/libm.so.6 (0xb73e7000)
      22. libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb73ca000)
      23. /lib/ld-linux.so.2 (0xb77ad000)
      24. libpcre.so.3 => /lib/i386-linux-gnu/libpcre.so.3 (0xb738c000)
      25. librt.so.1 => /lib/i386-linux-gnu/i686/cmov/librt.so.1 (0xb7383000)
      26. lars@cnc:/tmp$ sudo cp /usr/bin/mb2hal /usr/bin/mb2hal.backup
      27. lars@cnc:/tmp$ sudo cp temp/usr/bin/mb2hal /usr/bin/mb2hal
      Display All
      Der "ldd" Befehl schaut noch ob alle dynamischen Bibliotheken gefunden werden. Falls dort irgendwo "not found" stehen sollte, dann solltest Du dort aufhören und die Kopier-Kommandos nicht ausführen.

      Man kann das sicher auch irgendwie mit der Maus machen, aber das ist mir immer zu umständlich, auch wenn es für einen Anfänger wahrscheinlich erst mal intuitiver wäre. Außerdem kann man es schlechter hier reinkopieren. :)

      Damit solltest Du dann eine (hoffentlich mit Deinem FU funktionierende) mb2hal-Version auf Deiner Maschine haben. Die muss aber auf jeden Fall noch konfiguriert werden. Dazu solltest Du Dir, wie schon geschrieben, die Konfigurationsdateien vom Parker AC10 und das Handbuch vom Powtran nehmen und das versuchen entsprechend anzupassen.

      Zum Testen fand ich es besser linuxcnc aus einem Terminal heraus zu starten, da man dort direkt die Meldungen von mb2hal mitlesen kann.

      Tschüss,
      Lars
    • Hi Lars.

      Besten Dank für die Erklärungen. Jetzt verstehe ich das ganze langsam.... ;)

      Ich werde das nach deiner Anleitung, sobald ich Zeit habe, ausprobieren!



      chaotix wrote:

      Damit solltest Du dann eine (hoffentlich mit Deinem FU funktionierende) mb2hal-Version auf Deiner Maschine haben. Die muss aber auf jeden Fall noch konfiguriert werden. Dazu solltest Du Dir, wie schon geschrieben, die Konfigurationsdateien vom Parker AC10 und das Handbuch vom Powtran nehmen und das versuchen entsprechend anzupassen.

      Ja das ist mir klar. Das sollte ich aber rausfinden denke ich. Sobald die MB2HAL Datei da ist werde ich das dann testen.



      chaotix wrote:

      Zum Testen fand ich es besser linuxcnc aus einem Terminal heraus zu starten, da man dort direkt die Meldungen von mb2hal mitlesen kann.

      Du meinst damit, dass du LinuxCNC in einer VirtualMachine laufen lässt und dann sehen kannst was sie sendet?
      Oder was ist genau mit Terminal gemeint?


      Gruss

      Michi :)
    • Andreas hat natürlich völlig recht.

      Ist in der Standard-Desktop-Umgebung unter "Anwendungsmenü->Terminal" zu finden.

      Das ist auch das "Fenster", wo Du die Befehle von mir, die ich oben geschrieben habe, eintippen/reinkopieren musst.
      Alles vor dem "$" ist der "Prompt" und wird von der Eingabeaufforderung/Shell ausgegeben. Du musst nur die Sachen nach diesem Prompt bis zum ersten Zeilenumbruch eingeben. Die Zeilen ohne "$" sind die Ausgabe der gestarteten Programme.

      Der Prompt zeigt außerdem an, in welchem Verzeichnis Du bist. Wenn Du ein neues Terminal-Fenster (oder einen neuen Reiter) startest, dann bist Du normalerweise in Deinem Home-Verzeichnis, welches mit "~" abgekürzt wird. Wenn Dein User z.B. "lars" heißt, dann würde °~" für "/home/lars" stehen. Der Prompt "lars@cnc:~$" sagt also, dass der User "lars" an dem Rechner "cnc" eingeloggt ist und aktuell im Home-Verzeichnis ist.

      Die Konfigurationsdateien von LinuxCNC sind unter ~/linuxcnc/configs abgespeichert, wobei jede konfigurierte Maschine ein eigenes Unterverzeichnis bekommt. Wenn Du also Deine Maschine in LinuxCNC z.B. "CNC" genannt hast, dann würdest Du LinuxCNC folgendermaßen im Terminal starten:

      Source Code

      1. lars@cnc:~$ linuxcnc linuxcnc/configs/CNC/CNC.ini
      2. LINUXCNC - 2.7.14
      3. Machine configuration directory is '/home/lars/linuxcnc/configs/CNC'
      4. Machine configuration file is 'CNC.ini.expanded'
      5. Starting LinuxCNC...
      6. Found file(REL): ./CNC.hal
      7. Found file(REL): ./custom.hal
      8. mb2hal parse_common_section DEBUG: [MB2HAL_INIT] [INIT_DEBUG] [3]
      9. spindle-vfd parse_common_section DEBUG: [MB2HAL_INIT] [HAL_MODULE_NAME] [spindle-vfd]
      10. spindle-vfd parse_common_section DEBUG: [MB2HAL_INIT] [SLOWDOWN] [0.000]
      11. spindle-vfd parse_common_section DEBUG: [MB2HAL_INIT] [TOTAL_TRANSACTIONS] [4]
      12. spindle-vfd parse_transaction_section DEBUG: [TRANSACTION_00] [LINK_TYPE] [serial] [0]
      13. spindle-vfd parse_serial_subsection DEBUG: [TRANSACTION_00] [SERIAL_PORT] [/dev/ttyUSB0]
      14. spindle-vfd parse_serial_subsection DEBUG: [TRANSACTION_00] [SERIAL_BAUD] [9600]
      15. spindle-vfd parse_serial_subsection DEBUG: [TRANSACTION_00] [SERIAL_BITS] [8]
      16. spindle-vfd parse_serial_subsection DEBUG: [TRANSACTION_00] [SERIAL_PARITY] [none]
      17. spindle-vfd parse_serial_subsection DEBUG: [TRANSACTION_00] [SERIAL_STOP] [2]
      18. spindle-vfd parse_serial_subsection DEBUG: [TRANSACTION_00] [SERIAL_DELAY_MS] [150]
      19. spindle-vfd parse_transaction_section DEBUG: [TRANSACTION_00] [MB_SLAVE_ID] [1]
      20. spindle-vfd parse_transaction_section DEBUG: [TRANSACTION_00] [FIRST_ELEMENT] [4101]
      21. spindle-vfd parse_transaction_section DEBUG: [TRANSACTION_00] [PIN_NAMES] [status,dummy,temp]
      22. spindle-vfd parse_transaction_section DEBUG: [TRANSACTION_00] [NELEMENTS] [3]
      23. spindle-vfd parse_transaction_section DEBUG: [TRANSACTION_00] [MAX_UPDATE_RATE] [2.000]
      24. spindle-vfd parse_transaction_section DEBUG: [TRANSACTION_00] [MB_RESPONSE_TIMEOUT_MS] [500]
      25. spindle-vfd parse_transaction_section DEBUG: [TRANSACTION_00] [MB_BYTE_TIMEOUT_MS] [5000]
      26. spindle-vfd parse_transaction_section DEBUG: [TRANSACTION_00] [DEBUG] [1]
      27. spindle-vfd parse_transaction_section DEBUG: [TRANSACTION_00] [MB_TX_CODE] [fnct_03_read_holding_registers] [2]
      28. spindle-vfd parse_transaction_section DEBUG: [TRANSACTION_00] [HAL_TX_NAME] [info]
      29. spindle-vfd parse_ini_file OK: parse_transaction_section 0 OK
      30. [...]
      31. spindle-vfd parse_transaction_section DEBUG: [TRANSACTION_03] [LINK_TYPE] [serial] [0]
      32. spindle-vfd parse_serial_subsection DEBUG: [TRANSACTION_03] [SERIAL_PORT] [/dev/ttyUSB0]
      33. spindle-vfd parse_serial_subsection DEBUG: [TRANSACTION_03] [SERIAL_BAUD] [9600]
      34. spindle-vfd parse_serial_subsection DEBUG: [TRANSACTION_03] [SERIAL_BITS] [8]
      35. spindle-vfd parse_serial_subsection DEBUG: [TRANSACTION_03] [SERIAL_PARITY] [none]
      36. spindle-vfd parse_serial_subsection DEBUG: [TRANSACTION_03] [SERIAL_STOP] [2]
      37. spindle-vfd parse_serial_subsection DEBUG: [TRANSACTION_03] [SERIAL_DELAY_MS] [150]
      38. spindle-vfd parse_transaction_section DEBUG: [TRANSACTION_03] [MB_SLAVE_ID] [1]
      39. spindle-vfd parse_transaction_section DEBUG: [TRANSACTION_03] [FIRST_ELEMENT] [269]
      40. spindle-vfd parse_transaction_section DEBUG: [TRANSACTION_03] [PIN_NAMES] [hz]
      41. spindle-vfd parse_transaction_section DEBUG: [TRANSACTION_03] [NELEMENTS] [1]
      42. spindle-vfd parse_transaction_section DEBUG: [TRANSACTION_03] [MAX_UPDATE_RATE] [2.000]
      43. spindle-vfd parse_transaction_section DEBUG: [TRANSACTION_03] [MB_RESPONSE_TIMEOUT_MS] [500]
      44. spindle-vfd parse_transaction_section DEBUG: [TRANSACTION_03] [MB_BYTE_TIMEOUT_MS] [5000]
      45. spindle-vfd parse_transaction_section DEBUG: [TRANSACTION_03] [DEBUG] [1]
      46. spindle-vfd parse_transaction_section DEBUG: [TRANSACTION_03] [MB_TX_CODE] [fnct_06_write_single_register] [4]
      47. spindle-vfd parse_transaction_section DEBUG: [TRANSACTION_03] [HAL_TX_NAME] [frequency]
      48. spindle-vfd parse_ini_file OK: parse_transaction_section 3 OK
      49. spindle-vfd main OK: parse_ini_file done OK
      50. spindle-vfd init_mb_links DEBUG: LINK 0 (RTU) link_type[0] device[/dev/ttyUSB0] baud[9600] data[8] parity[N] stop[2] fd[-1]
      51. spindle-vfd main OK: init_gbl.mb_link done OK
      52. spindle-vfd init_mb_tx DEBUG: MB_TX 0 lk_n[0] tx_n[0] cfg_dbg[1] lk_dbg[0] t_inc[0.500] nxt_t[0.000]
      53. spindle-vfd init_mb_tx DEBUG: MB_TX 1 lk_n[0] tx_n[1] cfg_dbg[1] lk_dbg[0] t_inc[0.500] nxt_t[0.000]
      54. spindle-vfd init_mb_tx DEBUG: MB_TX 2 lk_n[0] tx_n[2] cfg_dbg[1] lk_dbg[0] t_inc[0.500] nxt_t[0.000]
      55. spindle-vfd init_mb_tx DEBUG: MB_TX 3 lk_n[0] tx_n[3] cfg_dbg[1] lk_dbg[0] t_inc[0.500] nxt_t[0.000]
      56. spindle-vfd main OK: init_gbl.mb_tx done OK
      57. spindle-vfd create_each_mb_tx_hal_pins DEBUG: mb_tx_num [0] pin_name [spindle-vfd.info.num_errors]
      58. spindle-vfd create_each_mb_tx_hal_pins DEBUG: mb_tx_num [0] pin_name [spindle-vfd.info.status]
      59. spindle-vfd create_each_mb_tx_hal_pins DEBUG: mb_tx_num [0] pin_name [spindle-vfd.info.dummy]
      60. spindle-vfd create_each_mb_tx_hal_pins DEBUG: mb_tx_num [0] pin_name [spindle-vfd.info.temp]
      61. spindle-vfd create_each_mb_tx_hal_pins DEBUG: mb_tx_num [1] pin_name [spindle-vfd.info2.num_errors]
      62. spindle-vfd create_each_mb_tx_hal_pins DEBUG: mb_tx_num [1] pin_name [spindle-vfd.info2.rpm]
      63. spindle-vfd create_each_mb_tx_hal_pins DEBUG: mb_tx_num [2] pin_name [spindle-vfd.runmode.num_errors]
      64. spindle-vfd create_each_mb_tx_hal_pins DEBUG: mb_tx_num [2] pin_name [spindle-vfd.runmode.command]
      65. spindle-vfd create_each_mb_tx_hal_pins DEBUG: mb_tx_num [3] pin_name [spindle-vfd.frequency.num_errors]
      66. spindle-vfd create_each_mb_tx_hal_pins DEBUG: mb_tx_num [3] pin_name [spindle-vfd.frequency.hz]
      67. spindle-vfd main OK: HAL components created OK
      68. spindle-vfd main OK: Link thread loop and logic 0 created OK
      69. spindle-vfd main OK: spindle-vfd is running
      70. spindle-vfd fnct_03_read_holding_registers ERR: mb_tx[0] mb_links[0] slave[1] = ret[-1] fd[4]
      71. spindle-vfd link_loop_and_logic ERR: mb_tx_num[0] mb_links[0] thread[0] fd[4] transaction failure, num_errors[1]
      72. spindle-vfd fnct_03_read_holding_registers ERR: mb_tx[1] mb_links[0] slave[1] = ret[-1] fd[4]
      73. spindle-vfd link_loop_and_logic ERR: mb_tx_num[1] mb_links[0] thread[0] fd[4] transaction failure, num_errors[1]
      Display All

      Da siehst Du dann auch, was ich mit den mb2hal-Ausgaben meine. Am Anfang sind Debug-Meldungen, wo alle konfigurierten Transaktionen der Konfigurationsdatei aufgelistet werden. Dort sieht man dann, ob alles so ist, wie man das haben will und dass man keine Syntax-Fehler eingebaut hat.
      Am Schluss siehst Du Fehlermeldungen, dass die Kommunikation mit dem FU nicht funktioniert hat (weil ich für diesen Test den FU nicht eingeschaltet hatte).

      Wenn man diesen ganzen Wust an Meldungen nicht mehr ausgegeben haben möchte, kann man in der mb2hal.ini-Datei INIT_DEBUG niedriger als "3" setzen.

      Ich hoffe, das hilft,
      Lars
    • Ja das mit dem Terminalbefehlen habe ich verstanden, ich wusste am Anfang nur nicht genau wie das gemeint ist daraus zu starten.

      Nun ist es klar :)

      Ich konnte die MB2HAL Komponente über das Terminal erfolgreich installieren und meine bestehende, konfigurierte Linux CNC Version startet auch immer noch ohne Fehler auf :)



      Ich habe mir einmal die Parameter angesehen und versucht diese zu überprüfen und anzupassen.


      Parameter für Start (rechts, links) und Stopp:

      Konfigurationsdateien:

      Source Code

      1. Aus der ini Datei:
      2. [TRANSACTION_02]
      3. MB_TX_CODE=fnct_06_write_single_register
      4. FIRST_ELEMENT=8192
      5. HAL_TX_NAME=runmode
      6. PIN_NAMES=command
      7. Aus der hal Datei:
      8. # Choose command: Forward/Reverse/Stop
      9. setp mux4.runmode.in0 3 # Dec. stop
      10. setp mux4.runmode.in1 2 # Reverse
      11. setp mux4.runmode.in2 3 # Dec. stop
      12. setp mux4.runmode.in3 1 # Forward
      13. net spindle-on motion.spindle-on => mux4.runmode.sel0
      14. net spindle-fwd motion.spindle-forward => mux4.runmode.sel1
      15. net spindle-runmode mux4.runmode.out => spindle-vfd.runmode.command
      Display All

      Powtran Manual:


      Register 8192 Dez -> 2000 Hex sind gleich!
      Die Parameter für Links und Rechtslauf sowie Stopp sind die gleichen, dass müsste also passen


      Prameter für Frequenz:

      Die Frequenzberechnung verstehe ich aber noch nicht ganz...
      Was wird hier mit der Frequenz genau gerechnet? Und für was wird eine Min- und Maximumfrequenz benötigt?

      Source Code

      1. Aus der ini Datei:
      2. [TRANSACTION_03]
      3. #MB_TX_CODE=fnct_03_read_holding_registers
      4. MB_TX_CODE=fnct_06_write_single_register
      5. FIRST_ELEMENT=269
      6. HAL_TX_NAME=frequency
      7. PIN_NAMES=hz
      8. Aus der hal Datei:
      9. # Calculate frequency from desired speed
      10. net spindle-speed motion.spindle-speed-out-abs => mult2.freq.in0
      11. setp mult2.freq.in1 1.666667 # 100 / 120 * motor poles
      12. net spindle-speed-raw mult2.freq.out => limit1.freq.in
      13. # Limit speed output
      14. setp limit1.freq.min 10000 # Min. Frequency * 100
      15. setp limit1.freq.max 40000 # Max. Frequency * 100
      16. net spindle-speed-cmd limit1.freq.out => spindle-vfd.frequency.hz
      Display All

      Beim Powtran gibt es laut Manual 2 verschiedene Varianten die Frequenz einzustellen:



      Ich denke Mal dass die 1. Variante die einfachere ist.

      Müsste ich dann einfach in der ini Datei Adresse des FIRST_ELEMENT von 269 auf F001 (-> 61441 Dez) ändern richtig?
      (Je nach dem muss auch an der Berechnung noch etwas geändert werden...?)


      Parameter für die Statusinformationen:

      Da muss ich mich nochmals durchlesen, wie das mit dem Powtran genau funktioniert...


      Noch Grundlegend zur MB2HAL:

      Ich konnte, wie oben erwähnt, die neue MB2HAL erfolgreich installieren.
      Bei meiner vorhandenen LinuxCNC Konfiguration kam auch keine Fehlermeldung.

      Dann habe ich eine neue Konfiguration mit StepConf gemacht, und folgenden Haken gesetzt:



      Und anschliessend die Komponenten von der Parker 10 Seite eingefügt.

      Beim Starten dieser Version kommen dann aber immer Fehlermeldungen und das Programm beendet sich gleich wieder.

      Ich habe es leider grade nicht hier, aber werde die Fehlermeldungen dann möglichst bald noch hier reinstellen...


      Ist es aber Grundsätzlich so, dass wenn der FU nicht die richtigen, bzw. keine Daten zurücksendet dass Programm gar nicht startet?
      Oder hat das nichts damit zu tun und es sollte auch laufen wenn der FU nicht angeschlossen/ eingeschaltet ist?
      Denn dann habe ich noch irgendwo einen Fehler im Code...


      Gruss und besten Dank!

      Michi :)
    • Hallo.

      sutter.michi wrote:

      Prameter für Frequenz:
      Die Frequenzberechnung verstehe ich aber noch nicht ganz...
      Was wird hier mit der Frequenz genau gerechnet? Und für was wird eine Min- und Maximumfrequenz benötigt?
      Was Du für Minimal- und Maximal-Frequenzen hast, hängt von Deiner Spindel ab. Die sollten auch im FU konfiguriert worden sein.

      Zum Einstellen der Drehzahl wird beim Parker AC10 nicht die Drehzahl selber gesetzt, sondern eine Frequenz. (Und nach dem Auszug aus dem Handbuch, den Du hier reinkopiert hast, sieht es so aus, als ob das beim Powtran ähnlich ist.)

      Um von Drehzahl in Frequenz umzurechnen, dividiert man durch 120 und multipliziert mit der Anzahl der Pole der Spindel (ich schätze, das sollten bei Dir auch 2 sein). D.h. Frequenz = Drehzahl / 120 * 2 = Drehzahl / 60.

      Der Parker AC10 will nun allerdings nicht die Frequenz haben, sondern die Frequenz * 100. Daher multipliziere ich die Drehzahl mit 1.6667 (= 100 / 60). Anschließend wir nur noch sicher gestellt, dass sich die berechnete Frequenz im gültigen Bereich (zwischen Minimal- und Maximal-Frequenz) befindet.

      sutter.michi wrote:

      Ich denke Mal dass die 1. Variante die einfachere ist.

      Müsste ich dann einfach in der ini Datei Adresse des FIRST_ELEMENT von 269 auf F001 (-> 61441 Dez) ändern richtig?
      (Je nach dem muss auch an der Berechnung noch etwas geändert werden...?)
      Hört sich für mich soweit in Ordnung an. Was der FU jetzt allerdings konkret für einen Wert haben will, weiß ich nicht. Musst Du evtl. beim Handbuch unter dem entsprechenden Register nachschauen. Kann sein, dass er auch ein Vielfaches haben will, da per Modbus nur Ganzzahlen übertragen werden und Schritte von 1Hz evtl. für manche Anwendungszwecke zu ungenau sein könnten.

      sutter.michi wrote:

      Beim Starten dieser Version kommen dann aber immer Fehlermeldungen und das Programm beendet sich gleich wieder.

      Ich habe es leider grade nicht hier, aber werde die Fehlermeldungen dann möglichst bald noch hier reinstellen...

      Ist es aber Grundsätzlich so, dass wenn der FU nicht die richtigen, bzw. keine Daten zurücksendet dass Programm gar nicht startet?
      Oder hat das nichts damit zu tun und es sollte auch laufen wenn der FU nicht angeschlossen/ eingeschaltet ist?
      Denn dann habe ich noch irgendwo einen Fehler im Code...
      Ohne Fehlermeldung kann ich da nichts zu sagen.

      Eine erfolgreiche Kommunikation mit dem FU ist nicht erforderlich, damit LinuxCNC startet. D.h. Du hast wahrscheinlich irgendwo in den Konfigurationsdateien einen Fehler. Wo und was das ist, steht in den Fehlermeldungen.

      Tschüss,
      Lars
    • Hi Lars.

      Ich werde wohl doch Variante 2 verwenden.

      Hier muss ich die Drehzahl dann in eine Frequenz umrechnen und in einem Prozentwert übermitteln.
      => 100% entsprechen der Maximalfrequenz
      => 100% = Wert 10000 (Dez.)
      => Werte werden ins Register 0x1000 geschrieben

      Damit sollte auch das Problem mit den mit übermittelbaren Nachkommastellen gelöst sein. Denn 10000 entsprechen ja 100.00%. Eigentlich also fast das gleiche wie beim AC10 :)

      Das werde ich mit deiner Anleitung oben einmal versuchen zu berechnen, bzw so einzustellen ;)

      Ich finde aktuell nur leider keine Infos zu meiner 2.2kW Frässpindel. Ob diese 2 oder 4 Pole hat ...
      Im schlimmsten Fall ist ja aber einfach der Wert falsch und um Faktor 2 zu klein. Dann merke ich es spätestens beim austesten.


      Ich habe nochmals probiert LinuxCNC zu starten und irgendwie aus den Fehlermeldungen schlau zu werden.
      Leider komme ich da nicht weiter ...

      Ich habe das Gefühl, dass hier in der normalen .ini - Datein noch gewisse Sachen angepasst werden müssten?
      Kann das sein, finde ich das vielleicht selbst irgendwo raus?



      Im Anhang habe ich einmal meine Konfigurationsdateien eingefügt.
      Ich habe mir mal eine neue, eigene Test LinuxCNC Konfiguration (Namens Modbus) erstellt (Zum üben und wenn dann alles passt, werde ich es in mein funktionierendes Projekt einfügen/ ergänzen...)Deshalb nicht wundern wenn manche Sachen mit den Achsen oder so vielleicht keinen Sinn machen.


      Folgende Fehlermeldungen erhalte ich nach dem Starten:
      Dabei ist mir noch aufgefallen dass es ohne den eingesteckten USB-RS485 Wandler viel mehr Fehler gibt. Ich nehme also an dass es den zum Starten braucht! Richtig?


      Fehlerreport ohne eingesteckten RS485 Wandler:

      Fehlerreport - ohne USB-RS485 Wandler.txt


      Fehlerreport mit eingestecktem RS485 Wandler:

      Fehlerreport - mit USB-RS485 Wandler.txt




      Vielleicht siehts du grade woran es liegen könnte, oder könntest dir einmal die Konfig Dateien anschauen?


      Gruss und vielen Dank!!

      Michi :)
      Files

      The post was edited 2 times, last by sutter.michi ().

    • Hallo.

      sutter.michi wrote:

      Hier muss ich die Drehzahl dann in eine Frequenz umrechnen und in einem Prozentwert übermitteln.=> 100% entsprechen der Maximalfrequenz
      => 100% = Wert 10000 (Dez.)
      => Werte werden ins Register 0x1000 geschrieben
      Wenn Du Prozent übermittelst, dann musst Du nicht mehr mit der Frequenz rechnen. Deine maximale Drehzahl wirst Du ja kenne (z.B. 24.000). D.h. Du multiplizierst Deine gewünschte Drehzahl mit 100 / 24.000 * 100 = 0,416667. Das Ergebnis ist dann die gewünschte Drehzahl in Prozent * 100.

      sutter.michi wrote:

      Ich finde aktuell nur leider keine Infos zu meiner 2.2kW Frässpindel. Ob diese 2 oder 4 Pole hat ...
      Wie Albert schon schrieb: Mit an Sicherheit grenzender Wahrscheinlichkeit hat Deine Spindel 2 Pole.

      sutter.michi wrote:

      Ich habe nochmals probiert LinuxCNC zu starten und irgendwie aus den Fehlermeldungen schlau zu werden.
      Leider komme ich da nicht weiter ...
      Der Fehler ist im Abschnitt "Debug file information:" zu finden:
      ./custom.hal:33: Pin 'motion.spindle-speed-out-abs' was already linked to signal 'spindle-cmd-rpm-abs'

      Mit einem "grep motion.spindle-speed-out-abs *" sieht man dann auch, dass der besagt Pin ebenfalls in Modbus.hal zugewiesen wird.

      Bei mir habe ich die entsprechende Zeile in der "normalen" .hal-Datei einfach auskommentiert, da ich "spindle-cmd-rpm-abs" nicht weiter benötige.

      Tschüss,
      Lars
    • Super, nun startet mein Test-Programm ;)

      Ich musste allerdings noch folgenden Fehler beheben:

      Source Code

      1. Debug file information:
      2. .
      3. ./custom.hal:47: Pin 'iocontrol.0.user-enable-out' was already linked to signal 'estop-out'

      Dazu musste ich in der normalen .hal Datei folgendes auskommentieren:

      Source Code

      1. #net estop-out <= iocontrol.0.user-enable-out
      Ich muss mal noch rausfinden was diese Zeile genau bewirkt. Oder weist du vieleicht gerade was dieser Befehl macht, oder ob es unkritisch ist den auszukommentieren?



      chaotix wrote:

      Wie Albert schon schrieb: Mit an Sicherheit grenzender Wahrscheinlichkeit hat Deine Spindel 2 Pole.
      Okay, dann ist das schon mal klar.
      Die Frequenzberechung werde ich nacher gleich noch versuchen Nachzuvollziehen ... ;)


      Gruss Michi :)
    • sutter.michi wrote:


      Source Code

      1. Debug file information:
      2. .
      3. ./custom.hal:47: Pin 'iocontrol.0.user-enable-out' was already linked to signal 'estop-out'
      Dazu musste ich in der normalen .hal Datei folgendes auskommentieren:


      Source Code

      1. #net estop-out <= iocontrol.0.user-enable-out


      Ich muss mal noch rausfinden was diese Zeile genau bewirkt. Oder weist du vieleicht gerade was dieser Befehl macht, oder ob es unkritisch ist den auszukommentieren?

      Du kannst auch die estop-Sachen aus der custom.hal auskommtieren. Da kannst Du Dir auch Gedanken drum machen, wenn die Maschine soweit läuft. (Aber nicht vergessen.)
      Das ist ja nur ein Beispiel, wie man auf einen Fehler vom FU reagiert und den estop schmeißen kann. Das muss man natürlich an seine persönliche Konfiguration anpassen.

      Tschüss,
      Lars
    • Okay, dann werde ich das so machen und die Funktionen für Nothalt dann anschliessend einfügen ....

      Das mit der Frequenz- und Drehzahl-Berechnung ist ja ganz simpel und so wohl die beste Lösung :)


      Das einzige wo ich mich jetzt noch drum kümmern muss, ist welche Werte und Statusmeldungen vom FU kommen. Bzw. in welcher Form und in welchen Registern.

      Gibt es mit Linux eventuell eine Möglichkeit die Daten welche er über den USB-RS485 Wandler sendet mitzuschreiben, bzw. anzuschauen? Eventuell im Terminal?

      Gruss Michi :)
    • sutter.michi wrote:

      Das einzige wo ich mich jetzt noch drum kümmern muss, ist welche Werte und Statusmeldungen vom FU kommen. Bzw. in welcher Form und in welchen Registern.
      Gibt es mit Linux eventuell eine Möglichkeit die Daten welche er über den USB-RS485 Wandler sendet mitzuschreiben, bzw. anzuschauen? Eventuell im Terminal?
      Wenn Du LinuxCNC im Terminal startet und mb2hal im Debug-Modus ist, dann kann man doch direkt alle Modbus-Transaktionen mitlesen.

      Das hilft Dir aber nicht das richtige Register zu finden. mb2hal muss man natürlich sagen, welche Register es abfragen soll. Modbus ist ein Master-Slave-Protokoll. D.h. von alleine macht der FU nichts. Er schickt also auch nicht von sich aus irgendwelche Status-Updates. Der Master (LinuxCNC bzw. mb2hal) muss das Status-Register regelmäßig anfordern und nur auf so eine Anforderung darf der FU dann Daten schicken.

      Daher musst Du die Informationen, wie Du an den Status des FUs kommst dem Handbuch entnehmen.
    • Hallo zusammen.

      Inzwischen habe ich die Kommunikation am laufen :)
      Sobald alles läuft, werde ich die Konfig Dateien hier reinstellen und wenn ich das kann/ darf bzw. rausfinde wie, dann natürlich auch noch auf LinuxCNC damit alle was davon haben ;)

      Ich kann die Spindel starten, stoppen, Drehzahl wird richtig übergeben und auch die aktuelle Drehzahl zurückgelesen!
      Die Fehler-Register-Auswertung konnte ich noch nicht testen...

      Wo ich aktuell noch am pröbeln bin, ist wie ich eine Verbindung von der hal in die xml datei bekomme.
      Ich würde mir gerne die aktuelle Soll Drehzahl dort anzeigen lassen.
      Eigentlich eine kleine Sache, aber es gibt immer einen Fehler sobald ich in der custom_postgui.hal eine neue net Verbindung mache.

      Muss das sonst noch irgendwo angepasst oder verknüpft werden?
      Ich werde auch nochmals danach suchen ...


      Hier Auschnitte aus dem Code mit den betreffenden Passagen:
      Es geht um den Befehl -> spindle-speed

      Source Code: custom.hal

      1. #=======================================================================#
      2. #Frequenzberechnung:
      3. #Drehzahl aus LinuxCNC in Prozentsatz von Maximaldrehzahl umrechnen
      4. #Prozentsatz * 100 damit keine Nachkommastellen übertragen werden müssen
      5. #-> Maximaldrehzahl: 24000 U/min = 400 Hz = 100% = 10000 (Prozent * 100)
      6. net spindle-speed motion.spindle-speed-out-abs => mult2.freq.in0 #<- Drehzahl aus LinuxCNC einlesen...
      7. setp mult2.freq.in1 0.416667 #mit 0.416667 multiplizieren (-> 100/24000 * 100 = 0.41667 => Prozentwert der Drezahl * 100)
      8. net spindle-speed-raw mult2.freq.out => limit1.freq.in #-> an Drehzahlüberprüfung weitergeben...


      Hier Verknüpfe ich ihn mit pyvcp (auskommentierte Zeile):

      Source Code: custom_postgui.hal

      1. # Benutzerdefinierte HAL-Anweisungen können nachfolgend angegeben werden
      2. # Die Befehle in dieser Datei werden nach der AXIS GUI (und PyVCP-Panel) ausgeführt.
      3. net vfd-temp pyvcp.vfd-temp #Temperaturanzeige (aktuell noch nicht konfiguriert!!!)
      4. net spindle-at-speed pyvcp.spindle-at-speed #Anzeige: Spindel auf Solldrehzahl
      5. #net spindle-speed pyvcp.spindle-speed
      6. net spindle-speed-in-fu pyvcp.spindle-speed-in #Anzeige: Spindel Solldrehzahl

      XML zur anzeige in der Axis GUI:

      Source Code: custompanel.xml

      1. <tablerow/>
      2. <tablesticky sticky="w"/>
      3. <label>
      4. <text>"Soll Drehzahl:"</text>
      5. </label>
      6. <tablesticky sticky="e"/>
      7. <s32>
      8. <halpin>"spindle-speed"</halpin>
      9. <format>"dU/min"</format>
      10. </s32>

      - Die custom.hal funktioniert. Das wurde getestet und lief auch schon vor den Anpassungen im xml.
      - An der xml Datei kann es auch nicht liegen, denn wenn ich im custom_postgui.hal die entsprechende Zeile auskommentiere, dann startet alles ohne Fehlermeldungen...

      -> Ich denke es muss irgendwie an der custom_postgui.hal liegen, aber ich habe noch nicht herausgefunden wo der Fehler steckt.

      Vielleicht fällt es jemandem von euch auf?


      Gruss

      Michi :)