Advanced Search

greg23_78 wrote:

I no longer get errors but it still doesn't work, my pin axisui.run-disable remains on false while my input hm2_7i97.0.inmux.00.input-11-not works fine

I think that probably means that the postgui HAL file isn't being executed. Did you add the postgui file to the [HAL] section of the INI file?

USB to Serial isn't relevant here. I think that plug is intended for transferring G-code to the controller, not for machine control.

USB to parallel won't work either.

Do you have a PC with a physical parallel port? (some have one as headers on the motherboard, but don't connect it to the rear panel)

You could also consider using a Raspberry Pi 4 (not 5 at the moment) but there isn't a config wizard for the Pi GPIO pins.

Is there any more? This doesn't get as far as reporting the actual error.

There might be a way to do what you want, but I am not sure how.

What happens if you remove the reference to A from the position.txt file before you restart LinuxCNC?

You can almost certainly do his by creating a custom homing routine, but I would hope that there is a simpler way than that,

I think that I have looked into this in the past, and found that it was fairly easy to change the postprocessor file based on the results of a Google search.

What is the problem? Is it that the postprocessing fails when you try to create the G-code?

The best way to report an error in the docs is to raise an issue at:
github.com/LinuxCNC/linuxcnc/issues

But there is no need to do that here, as I just fixed it.

Thanks for the correction.

In Stepconf you can only pick one function for each parallel port pin, but that doesn't mean that LinuxCNC doesn't support it.

Create a config with Z-home not allocated, then when the config is finished, edit the HAL file by hand.

You will see a line looking something like:

Edit that to say

If you want you can also change the signal name (home_Y2) to something that makes more sense to you.

Also, I am guessing the joint-to-axis allocations, so the numbers above might not be right. Adapt the numbers to suit your actual config.

Soooorta.

So the drive needs to be 135v or it will toast the spindle. BUT, you are 100% right in that lowering the voltage has some some sort of math and reduced the power.

After working with the drive support people, we did a few things. ! was to boost the carrier frequency to 16khz. this reduced current a lot (over an amp at load). Then we upped the voltage bit by bit until we found a compromise where it is no longer bogging down, but also not getting more than slightly warm. Idles at 2.1A now.

As a result, I have about 600w usable power at 5A draw, no bogging down, and it's "fine" for now, until I can wrangle a high speed drive.

just subscribing to this thread...

Anyone tune these up yet and move a machine? Very curious to see how they perform. When you factor cables and psus, these come out even cheaper than JMC integrated servos, and less than half of delta b3s, so id lover to see how they actually perform.

Ok had a play around.Build works OKFlashing works okAfter flashing, when SPI interface not connected, no blinking lights observed.Has to create a new board called Mimas, and the config to go with.Just copied the Spartan6 stuff.After generating everything has browse thru the Ouput/Mimas/Gateware folder everthing was there, pin constraints matched what I need. Just added the "drive setup" for each pin.Still need to setup the Rpi for Linuxcnc.Included some file for you to look at.

linuxcnc.org/docs/html/hal/basic-hal.html#sub:hal-addf

The addf command adds a function to a real-time thread

Addf
Then the function
Then the thread the function is assigned to

Lcec is linuxcnc ethercat

Linuxcnc has has long-standing terminology of:
Servo thread - thread/loop where position, IO etc are read / updated
Base thread - used for software step generation. Not used in setups with hardware step generation (e.g. Mesa) or ethercat
(Documentation about the real time threads is a bit poor compared to most other linuxcnc docs)

Hi msrdiesel,

It would be awesome if you could share details on how you did your retrofit.
Especially about the spindel motor and spindel drive I'd like to learn more.

Thanks,

Frans

So I guess this is what I get from diving into EtherCat without already being super comfortable with LinuxCNC. I had seen it mentioned on the forum that it's a big task to work them both out at once and I have made it more complex by doing it on an RPI.

Seems my issue was while manipulating ethercat-conf.xml I was seeing seemingly good data appear in the lcec pins area of halshow, I was unable to manipulate them due to not having included the following in my Ini file.
addf lcec.read-all servo-thread
addf lcec.write-all servo-thread

Seems that it's not a servo thread but an overall thread for all IO (including servos) that these lines are referring to.

So, seems that I can operate all the digital outputs for this controller. I will continue to work on the other IO.

Thanks for the pointers on this everyone.

What does:

ping -i .2 -c 4 10.10.10.10
sudo chrt 99 ping -i .001 -q 10.10.10.10
 (let the last command run for a few minutes and
then stop it with a control C, it will print timing statistics)

report?
 

"Watchdog has bit" usually means really bad latency (>5 ms)

Running

halcmd show param *.tmax

in a terminal when LinuxCNC is running
will give more information

What is the host hardware and clock speed?

Also do you have all power management/turbo modes/speedstep
etc disable in the BIOS?  Really bad latency is quite often related
to CPU power management.