Advanced Search

Hakan wrote:

If the drive is reducing the speed by itself you will get following errors.
Otherwise it's the settings in the ini file that are throttling the speed.

Yeh, that's what I have been playing with to determine where to set max velocity. I remembered from when I set up my plasma on a Mesa card to see how much of its 10 Mhz bandwidth I could use that there was a physical limit to how fast you could step in the real world. That's why I cut back the settings here. The design target was 10240mm/min so it fell a bit short, But the RPM is still quite respectable. I've had enough for one night.

I also might try increasing the amps a bit too

If the drive is reducing the speed by itself you will get following errors.
Otherwise it's the settings in the ini file that are throttling the speed.

So I had this theory that at default 10000 steps/rev it was running out of bandwidth when it got to 2000 mm/min (400 rpm). S0 I changed the steps to 1000 steps/rev which I assumed might get me to 10 x 2000 = 20000 mm/min
This let me get up to 8500 mm/min maximum velocity. But It did not get me to the expected 20000 mm/min (10 x 2000)
So definitely reduce the steps/rev if top end speed is important to you. I think you'll need to tweak the steps/rev to suit your design parameters.

fenton06 wrote:

Looks like the Trixie issues repo got nuked, does anyone know what happened?

Mental health issues.

Today I was able to get the spindle to rotate, but I've encountered two new problems. While the DI4 wire is connected to pin 16 of the bobbin to reverse the spindle's rotation, it always remains reversed, regardless of whether pin 16 is activated or deactivated. I checked with the HAL meter, and pin 16 is working correctly. I also measured with a multimeter, and when it's activated, it reads 0V, and when it's deactivated, it reads 5V, but the spindle always rotates in the same direction. Interestingly, when I disconnect the reverse wire from pin 16, it rotates in the correct direction, and if I reconnect it, it reverses direction, but nothing happens from the interface using pin 16.

The other problem is that the RPMs don't match, for example, an M3 S1000. I've tried to correct this unsuccessfully from both the driver and the HAL. I have a 1.58:1 pulley ratio (45mm motor pulley, 71mm spindle). My knowledge of Linux CNC is limited, and I'm not sure where to go from here.

I'm not sure if I've explained myself clearly. Sorry for my English.

Hi,

I'm interested.
I also have the problem that the connection disconnects after a while. For me, however, it's enough to close LCNC, disconnect the dongle, and reconnect it.
I'm interested in the feed setting of the rotary knob button.
This doesn't work; only the increments can be set. I was only able to solve this with a workaround.

Hi,

Is anybody interested in some development for the XHC WHB04B pendant? Both from a user perspective, but also with the development itself.

I bought a WHB04B-6 to use with my mill, thinking it should work okay. But of course there are issues. After a while, it disconnects and I have to restart LinuxCNC to get it back working.

I have already went quite deep with this, and have some and can generate more material:
 - USB packet captures with Wireshark (form both LinuxCNC and Mach3)
 - USB signal capture with logic analyser
 - WHB04B transmitter firmware
 - RF signal capture

One thing I noticed with the xhc-whb04b-6 component in LinuxCNC is that is has some blocking wait states. These can delay the USB polling of the WHB04B so much that it causes the device to reset. I fixed that (for myself), but still there are issues...

There are several possibilities:
 - improve the xhc-whb04b-6 component
 - create a new driver/component for the pendant, realtime if seen necessary
 - create a new firmware for the WHB04B transmitter, possibly also for the pendant itself

Any comments or thoughts from the community?

I guess many have the opinion that both wireless and USB pendants are a no go. Personally I don't see an issue at least for "garage application", provided its properly implemented. The main thing would be to have a watchdog monitoring the communication, which can (e)stop the machine if necessary.

Here is pwm.txt - only analog=0 

You need to checkout the correct branch. The release versions are defined by a tag dso that are locked in. You can see this in git on the branch drop down if you select the tag tab. This will let you see the exact source for the version you have.

to get the source of 2.9.8 on your pc its  :git checkout v2.9.8

Hakan wrote:

Are the settings only possible through their software?
There are no SDOs for setting such things? Like Rtelligent has?

Yes there is. I will load the sdo docs on my NAS later, Seems like the app gives you access to all the SDOs and you can save them to a text file for later reimport so if you had a few of these drives it would be easy. The sdo docs sometimes have a better description.  You could make these settings from the command line using the ethercat app without putting in your XML. They show as bring Read/Write so hopefully they can be accessed when homing.eg reduce motor power when homing

Are the settings only possible through their software?
There are no SDOs for setting such things? Like Rtelligent has?

found it! I hope. More in a minute!
@hakan Yes, I experimented until I got a max velocity of 2000 mm/min which was roughly 400 rpm! So no fb when homing is not fixed. That I want to sort out. I'll stay on this config until I work this drive out

@NWE In the windows config program Plug it into the USB on the drive. It is safe to leave plugged into Linuxcnc (check thw com port in Device manager) before ruunning the software.

There was a setting  #25 PA_055 "The percentage unit of current of the lock machine" was set to 40%. Changed it back to 100%
I had previously set the current #21 PA_051 to 2 amps (2000 mA) so it did not have much) So now I will play with max velocities now to confirm its what I think it is.
 

Nope, design a machine instead.

It moved!
I only tried the second motor yet with my finger on the shaft
halcmd: setp lcec.0.0.1-target-position 0
halcmd: setp lcec.0.0.1-target-position 20
halcmd: setp lcec.0.0.1-target-position 0
halcmd: setp lcec.0.0.1-target-position 20
halcmd: setp lcec.0.0.1-target-position 0
halcmd: setp lcec.0.0.1-target-position 20

each time I felt a twitch

Now I better grab some sleep

This is looking better. Now I need to tape flag those motor shafts so I can see if they moved like my terminal claimed. Wait, keyboard's wireless, it CAN reach from my desk to my workbench...