Advanced Search

Cant do this anymore bye all wrote:

Something is amiss as the kernel is about 11 months newer than the image you linked to.
Now to clear things up.
1: have all your attempts been with the image you linked to.
2: if so what is causing the discrepancy with the kernel build date.

With the previous driver the kernel driver that was loaded on boot was unloaded by the Linuxcnc driver. I’m not entirely sure if it reloaded on exit.

Everything prior to today, was with the official Raspbian image.

Started with a fresh SD Card for the Debian image linked above today.
Would running system updates have messed with the kernel version?

OK, then usually this is due to old version of mesaflash, see this for latest version
forum.linuxcnc.org/27-driver-boards/5489...-see-the-card#317821

Edit:
Just went back on this, you asked mesaflash to verify is the board has the pwm version and it does not, hence the result.
You would need to flash the board first with the firmware you need, and the files are on the Mesa web page
www.mesanet.com/software/parallel/7i96s.zip

Something is amiss as the kernel is about 11 months newer than the image you linked to.
Now to clear things up.
1: have all your attempts been with the image you linked to.
2: if so what is causing the discrepancy with the kernel build date.

With the previous driver the kernel driver that was loaded on boot was unloaded by the Linuxcnc driver. I’m not entirely sure if it reloaded on exit.

Yeah a bit explained like i usually do
But still valid in both cases, baud rate is the rate of pulses/changes regardless of protocol, bit rate is what changes depending on data/protocol type and the control bits used.

Finally got the connection going. For newbie’s to Linuxcnc the leds on the 7i97t Ethernet port should be flickering while you’re pinging the ip address from the computer’s terminal. 
such a simple piece of information. 
I managed to figure out with my wifi connection ON, the Ethernet connection is dropped so simply disconnecting the WiFi connection allowed the connection with the mesa board.

Thanks vrnf 
I’ll have a look at updating mesaflash tomorrow.

Have you retrofitted your mh600w? Or still running the 432?


 

Actually tommy if you look at a serial transmission waveform the signal doesn’t change for every bit sent. If you send 0x00 or 0xFF you’ll see what l mean. Send a string of either value and it will kind of blow google’s answer out of the water.
By google’s definition baud rate will change depending on the data sent.

And if you read carefully the definition you copied and pasted baud rate is defined twice with different definitions.

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!