Advanced Search

Hi Andy, I have machines with Axor MicroSpeed ​​MCS-60-10/20 and HDT Colibri CB060 10/20 servo drives, among others, that have analog and PWM interfaces. According to the datasheets, they explain that they have some solder jumpers that can be connected to switch between interfaces, since they have PWM and analog. I've actually tried everything but I can't change the interface.
These servo drives operate up to 60V VDC, and the VDC motor machines for this voltage also have power supplies based on transformers, rectifiers, and fairly expensive capacitors that I could use and wouldn't have to change.
If you have any information on how to change these interfaces on the driver itself, that would be great. The datasheets for both brands specify that there is a solder jumper (example: K# nomenclature) to make this change, but when you look at the PCB, you find all the jumpers except that K#. Hahaha, the components come without identification, for a change, etc. It's also always fun to write a driver for a new module, in case it doesn't exist of course, thanks for the ideas and greetings

Yes, the eStop works as it should. By MPG, I mean a normal external handwheel with a selector switch for the axes, not the NV MPG.

cakeslob wrote:

Ok great, so

DarkPheonix - good for now and stepping?

Warning: Spoiler!

aDm1N - you have the Estop behavior working properly with that code then? If yes, Spyder, refer to his example.
re- MPG , here is the config for MPG, un-comment the line from your ini file, and make sure the component is installed. This is for the NVMPG that can come with the board with the screen. If you are talking about a separate MPG, we can copy the same with a few changes.
github.com/scottalford75/Remora-RT1052-c...ic/remora-nv-mpg.hal

re- C axis and encoder - this is more involved, lets circle back to this one

Spyder, yes there will be some conflicting line, the 3 lines at the top of the hal file needed modification, but I think you figured it out. "net remote-estp " check out the linuxcnc page on hal, but the nets are names that you create, so there wont be a remote-estp pin in the linuxcnc documents, and yes the => and <= denote signal direction,
so for example the new net "remote-estp" is connecting the linuxcnc pin "estop-latch.0.fault-in" to the remora pin "remora.input.04"
and the remora pin is going to the latch.0.fault-in pin

 
 

There is only one problem when you use the directional buttons to move the axes, the movement is strange, not responsive, slow to start, and sometimes that movement remains in memory, after an estop, the car exiting the estop starts turning again by itself or makes strange movements.!! but gcode work fine! i need study the problem! I was able to get it working using a function generator and an osciloscope.

According to the manual, parameter 2301 indicates open/closed loop and is set to open loop:

ethercat upload -p 0 -t int16 0x2301 0
0x0001 1

The shafts make no motion at all, the velocity display changes to 200 for an instant and then back to zero.  I can easily turn the motor shafts 

It looks like the operation mode is not set. The manual says to use CSP mode by setting 6060 to 8, then set 6040 to 0x6, 0x7, and 0xf in sequence

ethercat upload -p 0 -t int8 0x6060 0
0x00 0
ethercat download -p 0 -t int8 0x6060 0 8
ethercat upload -p 0 -t int8 0x6060 0
0x00 0

so the value is not being set via ethercat. How should I do this?

You will not be helped by knowing command 110.
It's the following error on the line above one need to react on.

They move a tiny tiny bit or not at all? Does the shaft stop free rotation?
Anyway, the drives are closed loop drives, you need to set them to open loop mode so they ignore the input from the non-existent encoder on the motors.
I searched briefly for a manual but couldn't find one - Lichuan CL3-E57H?
So you have to look in the manual, or perhaps there is a configuration software with it, I saw comments that suggests that. Turn of closed loop, enable open loop.
Hopefully it is that easy.
 

RPI5 with a 7i96, and after some time I get a solid red INIT light on the mesa card, and obviously at that point have to reset the card to continue.

If the init light turns on when LinuxCNC is running, (with any Mesa Ethernet FPGA card)
it means you have a watchdog fault, likely because communications have been lost
for longer than the watchdog timeout setting. This is likely due to a network latency issue.
No reset is needed, though LinuxCNC will have to be restarted.

Can you enter in MDI

(debug,#5410)

to see what diameter linuxcnc use in gcode

Hi Pcw,

Thanks for your fast responce.

We have an issue on codeberg. I invested today to find why the scurve some times breaks. We then see a
vertical line in the plot of tpmod.curvel.
The curve kind of starting from vel=0 again. Jumping etc.

It seems if my base thread is set to 50000 (too fast),
the scurve lib is not able to finish the algo anymore. Resulting in strange behaviour.
Like a sqrt() function taking about 1 ms to complete, wich is absolulutely madness.

Now if i set the base thread to 80000. Everything goes fine.
So i thought, better you know this also.

The guy in italy had 6 axis ethercat running, very difficult .hal setup, constantly breaking the scurve every move,
even without clothoids.

So now i helped him with remote desktop for hours. And now with a simple config he runs ok. We don't know
his cause exactly. But we are happy the problem is gone now.


 

Ok great, so

DarkPheonix - good for now and stepping?

aDm1N - you have the Estop behavior working properly with that code then? If yes, Spyder, refer to his example.
re- MPG , here is the config for MPG, un-comment the line from your ini file, and make sure the component is installed. This is for the NVMPG that can come with the board with the screen. If you are talking about a separate MPG, we can copy the same with a few changes.
github.com/scottalford75/Remora-RT1052-c...ic/remora-nv-mpg.hal

re- C axis and encoder - this is more involved, lets circle back to this one

Spyder, yes there will be some conflicting line, the 3 lines at the top of the hal file needed modification, but I think you figured it out. "net remote-estp " check out the linuxcnc page on hal, but the nets are names that you create, so there wont be a remote-estp pin in the linuxcnc documents, and yes the => and <= denote signal direction,
so for example the new net "remote-estp" is connecting the linuxcnc pin "estop-latch.0.fault-in" to the remora pin "remora.input.04"
and the remora pin is going to the latch.0.fault-in pin

Hi,

What would it be a blessing if we can run Draftsight again on linux. But it's no cam solution.

I've tried all your suggestions. Unfortunately, none of them work.

The tool is in the spindle - no program is running --> Tool changed in the tool table --> Confirmed with Enter --> Clicked Apply --> Clicked Reload --> Then tried in MDI G43 - the diameter doesn't change in the tool info box.
 

Will test today or tomorrow.

andypugh wrote:

I noticed in the latest RotarySMP video that he is using FreeCAD.

So do i, for several years, i did whole machine design in FreeCAD and 3D printed the results
www.printables.com/model/876702-diy-cnc-...-writing-logos-etc-o

Hi Pcw,

Can you try once more with Mesa?

In the repository :
git pull
cd cmake
./build_cmake

Added pins to monitor at runtime:
tpmod.hal_component_max_cycle_time_ns
tpmod.hal_component_max_cycle_time_scurve_ns

Param to start with, also influences max acc :
tpmod.hal_max_jerk = 5

Then the above pins must stay below ~50000 nanosec at runtime.
Everything above 1000000 ns is bad.

We have now 3 configs wich run scurve. 1 is in Slowakia and runs like a rocket on delta servo's.
My ethercat steppers run, but not optimal as my desktop pc has bad latency. Base thread & ethercat apptime = 80000
Another machine is in Italy and had bad .hal config wich broke the scurve at runtime. Now that is fixed, it run's.

Hello, 

I'm not sure if this is the right sub-forum to put this, but it seems close.When I load a G-code file onto my mill running QtDragonHD, the code is initializing at the G53 machine origin (top front left corner of the work envelope), rather than G54 as called out in the code (work offset zero in the middle of the work envelope). Please see the attached image (sorry it's not a screenshot, I don't currently have an easy way to pull screenshots off the mill computer) and G-code. 

Does anyone know what I might be doing wrong with my configuration or code to have caused this?