Advanced Search

Are you using a MOSFET to heat the wire from the SKR? If so, I suggest reducing the PWM duty cycle and seeing what happens. First of all, try connecting the resistance wire directly to the power supply — reminder: this might help — and check whether the “Bad SPI Payload” messages still occur. You may also want to consider powering the resistance wire from a completely separate power source.

I was very close to replacing the Linux CNC with a different system.
The small inaccuracies make it very difficult for a newcomer.

I've spent several hours trying to get rapid override working. I happened to read about the change in the designation from MVO to RO. The Mesa Config program doesn't recognize this yet.
Then I noticed that the manual has the wrong name.
Instead of rapid.rapid-override, it should be rapid-override.
I have now entered the following manually and it finally seems to be working.

# ---max Geschwindigkeit Neufestsetzungs-Signale an Mesa Encoder - mpg (rapid override signals to mesa encoder - mpg)---

net ro-count     <=  [HMOT](CARD0).7i73.0.0.enc3.count

# verbinde max Geschwindigkeit Neufestetzung Inkrement - MPG (connect rapid override increments - MPG)

    setp halui.rapid-override.direct-value false
    setp halui.rapid-override.scale 0.01
    setp halui.rapid-override.count-enable true
net ro-count            =>  halui.rapid-override.counts

That did it. I didn't specify a subindex, since the drive manual said there isn't one for 0x607C. However, at least in this case, ethercat download doesn't work without it.

'ethercat download -p2 -t int32 0x607C 0 35951' works as expected.

Before I had a serious accident with a mouse that resulted in a 3.5 tonne Shizuoka mill turning up at the house, I converted my Bridgeport clone to CNC using a Chinese all-in-one controller from Newker. Those things in the photos are for the z axis drive, housing the closed loop stepper, timing belt drive and pulleys. I fitted a 16mm ballscrew where the original feed trip adjuster screw used to live, as this is much neater and robust than the usual arrangement with a ballscrew cantilevered in front of the head and required minimal modifications to the head. The top one is the final iteration.
Here's a picture of the basic mechanism, before the limit switches, encoder scale etc were fitted (otherwise you wouldn't see the ballscrew).
 
You inevitably lose some of the precious z axis travel due to the limit switches etc but I managed to minimise that and retain most of the 5" motion.

Hmm... With that brake on the R-axis I sort of need to enable/disable that Cybelec amp dynamically but still be able to move others.

Got it! I will connect halui.machine.is-on to hm2_7i80.0.pwmgen.00.enable. Then I will use a discrete output to independently enable the R-axis Cybelec servo amp as needed.

I think it should be safe to wire that pwmgen enable to machine.is-on. We have the e-stop circuit cutting power to all servos and hydraulics. Down motion of the RAM goes through a contactor wired to the foot pedal's down position. I don't need to worry about instantaneous motor deceleration overload of the 7i54 H-bridge outputs since it is only powering solenoid coils.

You can choose between free-run and DC-sync (and SM-sync but noone uses that).
But you are not set up for any of that at the moment.
Let's start with free-run
Add this to eeprom-generator
 
The 000 is the one I have in mind, but have both of them in there.
Save all, burn eeprom, compile and upload firmware in the usual way.
In ethercat-conf.xml leave out the <dcConf ... > statement for the slave. That makes it use free-run mode.
It should now work in free run mode. 
 

From the ethercat docs it looks like i should work. However I always use this syntax
ethercat -p 2 download 0x607c 0 0.
Actually what I always do first is to see which values the sdo has
ethercat -p 2 upload 0x607c 0
0x00000000 0
And then do the download.
ethercat -p 2 download 0x607c 0 1
to set it to 1.

unknown wrote:

Yeah wifi can be an issue sometimes.
It might be worth looking into some of the services that maybe running not is not required for a cnc machine, CUPS is one for example.  

With this configuration i will leave like this.
The next issue is i have a 12 inch touchscreen monitor 1024x768 resolution but the touch does not work.
I have another 22 inch touchscreen monitor and it works perfect.
I verify the xinput list and it register the touchscreen as Holtek touch.
I tried to enable the touchscreen with xinput enable 8 (device 8 as the touchscreen) but nothing works.


 

I'm trying to change a drive's home offset via SDO (can't be done via PDO). Executing the command 'ethercat download -p2 -t int32 0x607C 0' returns "SDO transfer aborted with code 0x06010000: unsupported access to an object"

Obviously it doesn't work. Why doesn't it work?

Everything I've found online simply parrots the failure code and doesn't say why.

I have the installed version of linuxcnc on the 2.9.7 version, ive tryed to follow the orders of previes posts but they are to old and much of the links dont work anymore, if i run it from terminal the only output i get is that the plugins for LED, Buttons etc. is missing

well done its working !
I need the distributed clocks working if i want it to be compatible with LinuxCNC ?

I saw that one, that was a new one to me.
How about not solving it, and instead go around it?
Add a PDO say scale as rxpdo? I mean anything useful, you don't need to do anything with it, just a place holder.
Then you don't need that declaration in main.cpp.
I have always had rxpdos so had not encountered that before.
I can try to see what's going on in the code a bit later.

Meister, I think it is how you go from the comfort zone with Twincat to the deep waters in linux.
I read and write eeprom with "ethercat sii_read" and "ethercat sii_write", the EEPROM_generator
gives me directly the eeprom to download in bin format. The tool you refer to can be used
to take an arbitrary xml file and turn into eeprom format for downloading. It's very useful,
one of the tools to keep in the toolchest.

What version of linuxcnc are you using?
Is it an installed version or a run in place version?
What specifically have you tried?
If you run qtdrasigner from a terminal, what does it print?

Thanks Hakan for the inputs.
After not finding any obvious issues using your suggestion, I did what I should have done in the first place and used TwinCAT to test the terminal.
And as it turns out, the terminal seems to be the issue despite being sold as working, I can't get it to output anything with TwinCAT either.
So I will get a new one and try again.