Advanced Search

Hi, you cannot use ST-Link utility to flash the RT1052. You will need to use pyOCD with an ST-link (probably need to flash the CMSIS-DAP firmware).

github.com/scottalford75/Remora-RT1052/tree/main/CMSIS-DAP

in that case you would want to utilize a different subroutine, there are several good ones out there, if you liked the one from qtdragon you can see if it was a subroutine, or check with the router guys, they use some good methods that would be more akin to your requirements

I did as you recommended, but in the PnPconfig under the "P2" configuration tab I can select for Pin0: "X-Achse StepGen"  assuming this is creates the stepper pulses - but how can I select the "DIR" function for Pin14 ???

Do I need to set "Anzahl der Schrittmotoren" (number of stepper motors)  to 0 as well ? 
Since I am using L297 drivers.

[Edit:]  OMG, no I understand the pinout display when selecting 3 stepper motors in the config.  This is really not easy to read, when selecting the stepper: the "0" covers 2 pins (IO0 and IO1) with ( I  assume since it is not explicitly given) the IO0-pin connected to X-Dir (when selecting X-axis) and IO1-pin connected to X-Step.

I took a while until I understood it.




 

The default 7I92 firmware is 7i92_7i76x2D.bit, and that matches your pinout

You should be able to to use pncconf with "7i92-Internal Data" and
"7i76x2 with one 7i76"  Then disable the sserial ports and encoder
(If you don't use one) and unused stepgens to regain control of
their GPIO pins
 

The network drivers are not real time so delays can ocurr when syncing with a real time thread. Telling the network drivers to use the same core as the Linuxcnc real time core (3 in this case) using CPU affinity, is a well established work around for this by those in the RT community but relatively new to Linuxcnc.

Also don't forget to disable energy efficient Ethernet.

Hi,
I had the setup running before I reinstalled my laptop with the latest LinuxCNC version - stupid me didn't backup the "ini" file for LinuxCNC and I need help to recreate it.

I do have a 7i92M (IP 10.10.10.10) and use a self-made stepper driver board at the P2 connector, with the following connections:
Parallelport-Pin / IO-7i92M / Function:
1 / IO-0 / X-DIR
14 / IO-1 / X-Step
2 / IO-2 / Y-DIR
13 / IO-3 / Y-Step
3 / IO-4 / Z-Dir
16 / IO-5 / Z-Step     

I ran LinuxCNC-PnPConfig, but did not find any proper board/setup, that allows me to select this particular connection/config.

I remember previously it was straightforward to configure the individual pins for a 7i92M board - now I am struggling.
I am not sure which firmware is on the 7i92M board - but I assume it is the default, since I did not change it.

Any help is appreciated !
Thx

[Edit:] I found my previous discussion on the same topic in this forum from 3 years ago, but it does not help me much, since I cannot select and assign DIR/Step signals to 7i92M pins:   forum.linuxcnc.org/39-pncconf/43847-7i92...and-pncconf?start=10

 

Building Linuxcnc on any hardware platforen is not difficult. I did a video of how to do it.


The  hard bit is to build  the PREEMPT_RT real time kernel as generally, there are no pre-built Debs for it. Using the 6.1.12 kernel and above will avoid the need to apply the RT patch to kernel source. This might help.

In my experience pushing open loop steppers to extremes, they only loose steps when they get hot which can take some time when operating. At this point your drives may be unable to compensate for position based on the encoder feedback due to lack of torque.
There are many variable to consider if this happens,

Can you try to replace this 2 lines from

to

CopperHead wrote:

My Current max acceleration is set to 25. 

An ideal acceleration for steppers on a plasma table is about 3000 mm/sec/sec (120 in/sec/sec)
if your table is not super rigid, you won't be able to achieve that
Going beyond that acceleration is possible but you need to know what you are doing in relation to stepper build/design and table build/design

Try disabling secure boot/EFI in your BIOS and start again

I get this error using the same install steps I have successfully used on other PCs. The message is "The efi file system creation in partition ## of SCSI1 (0,0,0) (sda) failed.

I'm booting off a DVD, I can run the live image from it with no problems

Thanks, if/when I ship the router up from France I will get in touch but hopefully I can get the sensor running sooner than that. Perhaps you would like to come down to the middle of nowhere southern France to help

I need to relocate my entire workshop back to Norway but as I am sure you know, finding a place in/near Oslo isn't exactly cheap.

Luke

Thanks Andy, I will give it a try and post with my issues I think a saw a demo file to get started with.

The complicating factor is that my workshop is in southern France and I only have a couple of weeks down here to get some parts made before going back to Oslo. I might be able to ship the router up but in the meantime my time is limited. I can do fully manual tool changes but it would sure be nice and probably more accurate if I didn't have to.

Lcvette wrote:

depends completely on your machine setup, probe basic's stock tool setter functionality is designed for repeatable length tool holders where the tool length offset will repeat when the tool is loaded. think CAT40 or BT40 or TTS type tool holders. in this regard the probe will also have its own tool length offset. the tool setter is used for initial measuring of the tools and is designed to be stationary on the table with a known distance from the spindle nose (gage line) to the tool setter triggered height. when a tool is then measured its length offset will be the difference between the spindle noses (gage line) distance to the tool setter's triggered height and the height recorded when the inserted tool triggeres the tool setter. this give the tools an actual tool length offset in relation to the spindle nose.

when using the touch probe you would be probing with the tool length offset for the touch probe active. when the surface is probed and the probed point recorded, the work offset is zeroed. when the probe is removed from the spindle and its length offset cancelled, the new current distance of the spindle nose above the work origin will change.

this method is useful as it uses a non moving standard for the length offset measurement point, the spindle nose. this is more useful for machines with many tools that have stored length offsets in the tool table. with this method, if you crash a probe and need to replace the stylus, all of the other tools are not tied to the probe acting as a master tool which will now need remeasuring. instead the probes tool length offset is the only thing that must be updated and all other tools will have no impact to their recorded length offsets.

for routers with non repeatable tool lengths in yay an er collet for instance, this method does not work.

do please give us additional information about your machine setup so we can better understand which method would be best suited for you to implement.

thanks,

Chris
 

 Thank you for your response.

My machine is an ER11 collet, so tool need to be measured again at each change.

My worry is that the actual method rely heavily on an accurate Z axis reference. When designing the machine, for me, end switch where just approximate boundaries to avoid crashes. So my Z end stop is just an Omron click switch . Repeatability is good when doing it back to back, but I am not confident over months period.

That's what my previous workflow was to probe work piece Z zero and tool setter height at each startup. Maybe I should apply same here, probe spindle height at each startup. Or maybe upgrade Z reference switch to something more precise.