Advanced Search

Cant do this anymore bye all wrote:

Could be. Looks like it could be a self built kernel, there are a couple of options relating to the real time kernel built.

Be interesting to know the origin of the installation. To get the hm2_spix driver I think you still need to build from source as the Rpi packages seem to have a July changelog.
 

FRESH START DEBIAN INSTALL ON 1/3/2025
After cloning www.linuxcnc.org/iso/rpi-5-debian-bookwo...23-11-17-1520.img.xz to an SD card, then building linuxCNC from source, and Mesflash from source, i am in the following state.
Upon boot after connecting the card:
Mesaflash can not see the card, same invalid cookie error.

After attempting mesaflash, I tried halcmd (loading the same 2 drivers as previously)
halcmd CAN see the card and it's pins.

NOTE: /dev/ only contains "spidev10.0" whereas my other install had "spidev0.0 , spidev0.1 and spidev1"

Thoughts on next steps?

Very cool, this looks like it's coming along nicely and you're even taking the time to write the documentation. Hopefully I'll get back around to my control panel project so I can dig into this.Any suggestion what example would be a good place to start for a control panel like this, where it has a touch screen but would mostly use physical controls? This would be for a small mill (3 axis with 4th) and I currently do toolsetting on change with Gmoccapy 

 

Well, no. No flashing ever happened. mesaflash instantly threw this error and stopped.

Cant do this anymore bye all wrote:

I guess SPI would tie you to an arm platform or trying to bit bang from the host PC.
SPI is not recommended for long distance runs (its only really meant to board comms), even 6 or so inches can be unreliable when approaching MHz speeds. Seen this when experimenting with a Mesa 7c81.

Serial can use differential signals if there is noise, SPI differential signals can play havoc with timing at speeds.

And in reality unless you have a real hardware serial port, the serial comms is USB (at the host PC), doesn't run in realtime......in fact there is no realtime serial driver for Linuxcnc.
 

I actually mentioned this before as you would think as much legacy is built into LinucCNC someone would have worked on an RT serial component. I know Andy replied something along the lines of "I was wondering the same thing" but didn't offer much insight.

Alot of miniPCs expose Intel UART on GPIO headers. I've gotten it to run at reasonably high baud rates but I've only actually used it at standard baud rates. You're pretty much on point about SPI though I2C does get used in alot of cabled applications, Every HDMI cable has I2C in it. It's pretty easy to convert UART to RS422 with just a transceiver IC so that's not a big deal, not sure if using UART for this has any real benefits being there is no RT component but that's one of the things I was hoping to try out as I'd think it'd be just as easy to setup with Arduino-Connector.

I pretty much dropped what I was doing with Arduino-Connector because the lag on the Python side was intolerable. I just looked at the git issues and somebody figured out that it was just due to some serial timeout settings so I'll probably start messing with it again. One problem is I wasn't thrilled about the way the matrix keyboard setup worked and I would up redesigning my key panel to use I2C IO expanders to use with something else that didn't get finished. Now I'm just hoping someone can get support for I2C IO into Arduino Connector so I can try that. I don't think it would be difficult, but I don't do much code myself.
 

Using the sims.ini file, I set up the following:
.
.
.
[RS274NGC]
INI_VARS = 1

[TOOLSETTER]
z_tool = -1
Z_TOOL_HOME = -0.1
X_TOOL_HOME = 0
Y_TOOL_HOME = -10.25


OK ... when I boot up the system, no errors are indicated.  I "home" the system, and switch to the MDI box.

I then put in the following command:

G0 Z#<_ini[TOOLSETTER]z_tool>

It errors and says that the variable doesn't exist.  Hmmm...   so I tried doing ..

#<_ini[TOOLSETTER]z_tool> = -1.25

It took that without issue...  I then executed 

G0 Z#<_ini[TOOLSETTER]z_tool>

and now it works.  hmmm..  What am I doing wrong?  It is supposed to have a variable defined during ini time... but it isn't, at least that is what I am seeing.

It is appearing to allocate the variable AFTER ok, but not during the ini ...    Please set me right.



 

Du bekommst einen Fehler für " halui.machine.is-on" das es doppelt belegt ist?
Du hast es ja auch 2x.
Einmal hier:
net maschine.ist-an halui.machine.is-on whb.halui.machine.is-on
Und einmal hier:
net machine-is-on halui.machine.is-on

Ist "machine-is-on" mit noch etwas verknüpft? Wenn nicht, schmeiß es raus.

Actually it throws the error when attempting to change tool from 0 to 1.
Would I be correct to say that unless probe routines are created and probe defined, then Probe Basic Lathe cannot be used as an interface for Lathe?

Axis works perfectly, so I can at least use that!

Apologies if this is an obvious thing, still learning here

Something tells me that this python reference to the os.path is incorrect?

Qtvcp python plugin found: /home/andy/.designer/plugins/python/qtvcp_plugin.py
Traceback (most recent call last):
  File "/home/andy/.designer/plugins/python/qtvcp_plugin.py", line 49, in <module>
    from qtvcp.plugins.dialog_plugin import *
  File "/home/andy/linuxcnc-dev/lib/python/qtvcp/plugins/dialog_plugin.py", line 5, in <module>
    from qtvcp.widgets.dialog_widget import *
  File "/home/andy/linuxcnc-dev/lib/python/qtvcp/widgets/dialog_widget.py", line 33, in <module>
    from qtvcp.widgets.versa_probe import VersaProbe
  File "/home/andy/linuxcnc-dev/lib/python/qtvcp/widgets/versa_probe.py", line 47, in <module>
    ICONPATH = os.path.join(PATH.find_image_path(), 'probe_icons')
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "<frozen posixpath>", line 76, in join
TypeError: expected str, bytes or os.PathLike object, not NoneType

Since OS is already included. Or perhaps the var isn't already defined?

Wow I never thought of needing to setup the probe first!
And yes was looking to use probing to calibrate tool offsets, have seen this done by at least one other person and it seemed a useful and reliable method

So the sim does not have probing configured for lathe either?

But to be honest, main reason for using QtPyVCP is because it looks so very, very, nice!

Did you do
mesaflash --addr 192.168.1.121 --device ETHER --reload
or power off/on the board after flashing?

Hi,

I'm trying to flash my 7i96s mesa card to get a second PWM (btw - I had a hard time finding this file. PCW always mentions the '7i96s-support-file-zip, but I have failed to locate it).

Card works ok and:
mesaflash --addr 192.168.1.121 --device ETHER --readhmid
works without problems and produces this output (abbreviated):

Configuration Name: HOSTMOT2

General configuration information:

  BoardName : MESA7I96
  FPGA Size: 20 KGates
  FPGA Pins: 256
  Number of IO Ports: 3
  Width of one I/O port: 17
  Clock Low frequency: 100.0000 MHz
  Clock High frequency: 200.0000 MHz
  IDROM Type: 3
  Instance Stride 0: 4
  Instance Stride 1: 64
  Register Stride 0: 256
  Register Stride 1: 256

Modules in configuration:

  Module: DPLL
  There are 1 of DPLL in configuration
  Version: 0
  Registers: 7
  BaseAddress: 7000
  ClockFrequency: 100.000 MHz
  Register Stride: 256 bytes
  Instance Stride: 4 bytes
...

I was a bit confused about the first line above, but it is indeed the 7i96S. At least that's what's written on the board.
Upon flashing, I get this:

markus@JanusL:~/mesa_firmware/7i96s_2pwm$ mesaflash --addr 192.168.1.121 --device ETHER --verify 7i96s_2pwmd.bin
Checking file... OK
  File type: Efinix bin file
Verifying FLASH memory sectors starting from 0x100000...
  |
Error at 0x10004B expected: 0xA but read: 0x16

Thanks
 

zelo, you speeds in your config arent that crazy. you should be abkle to go faster. if you are only seeing the issue with jogging, try doing a test, by lowering the accel and raising the velocity.

Hi all, I am trying to troubleshooting my router set up on qtdragon_hd  with manual tool change with a tool length sensor. It will run the tool length procedure just fine (without a multi-tool file loaded) and will run a single tool gcode no problem but starts yelling at me when I try to run anything with a M6 command. The issues are probably not with the gcode I am using but just to be sure can someone please send me a simple example of a part with three tool changes? I am using mm.

many thanks 

Luke 

 

Servos often drift when the controller (linuxcnc) is disabled.
The usual way to counteract this problem is to disable the servo drive when linuxcnc is in 'machine off'

For instance the signal 'x-enable' is the signal used to disable the X axes servo.

Your servo drive surely has a enable/disable connection.

Kein anhang???