Rotary weirdness - defies understanding

Rotary issues, I’ve solved with a convoluted workaround, but not actually solved.

The specifications are: RD 6445-S controller, v.26.01.19 firmware, RDWorks v.8.01.60. (at the moment, Lightburn is not in question- the LAN lead is also not connecting, for reasons I can’t figure)

Rotary (3phase) with wheels/rollers.

I bought the 6445-S controller a year ago, because it could supposedly control a rotary from the U plug of the controller, without Y needing to be disconnected… A great idea. before that we’d had the RDC 6442-S for 4 years.

I bought a separate drive, just for U. Wired it up to an aviation socket in the laser frame bed, wired it to the 6445 controller, and power.

Then that’s where it sat till yesterday, when I wanted to get it working, and calibrated. I’d downloaded some pages of info on that, but it all was no help. These Lightburn forums have much info, but no post was able to solve the issue, and for reasons I cannot fathom, the LAN port is not working, so for the last year I’ve painfully copied U-files to a USB stick, and plugged that in the controller, and fetched the files from there, deleting them shortly afterwards. You get used to it. (The PC is about 45 ft from the controller, so USB is not ideal)

The 26.01.19 firmware in the 6445-S is supposed to be ok.

RDW version 8.01.60 - I went into the list and selected 6445S as the model. I’ve been using it ok for the last year, no problems.

I created a file of width equal to the circumference of a cup, rotated it 90degrees clockwise, then, after setting the User parameters as rotary [on], Rotating axis [U], diameter 71mm, and the steps Ieft with the 1000 suggested, I checked rotary axis = U (not Y), and for now, I set origin as dead centre in the file, and saved it to send to the controller via a USB memory stick.

I plugged the rotary into the aviation socket. Used Z- key to lower the bed. Pressed U+ & - keys and the rotary moves back and forth with the console keys.

I went into console user settings, enabled rotary [yes], 10 000 steps per rotation for now, (write), went into vendor settings , checked motor, U out, but left it alone, but I disabled Y search for home upon bootup (to avoid possible frame slop issues)

The file opens up looking normal in the console, but when I pressed [frame], Y moves just as much as X, and U does not rotate at all.

I spend the next hour trying to figure things out. IN the end the ONLY way I got it to work was to unplug the green Y axis drive plug from the RD controller, and plug the green U drive plug into where Y was.

Then I needed to calibrate the steps per mm or per rotation, and after much trying, I set in the User settings, 10102.26 steps per rotation as pretty darned accurate, and in Vendor settings, for U motor, 6.929063 steps per micro-meter. (except the U figures are not happening, because the rotary is now plugged into the Y output from the controller.)

However, the file was flipped- a mirror image. Nothing I did would alter that. I changed U positive to U negative in vendor settings. No change. Finally I went into vendor settings for Y, and changed Y direction from negative, to positive.

That fixed it, and I could now laser a file and have it land on the rotary the way I set it up on the PC.

BUT, it’s a half-hearted joke of a process, because it is not using the U socket of the controller, but the Y socket, and the whole idea was to NOT have to unplug Y while using U/rotary.

Otherwise you have to remember to swap Y back to negative direction, and turn off rotary, and allow Y to home, before sending a normal file again.

What surprised me was every time I rebooted RD Works, it had forgotten ALL the user rotary settings, both diameter and steps per rotation, in the User menu.

Also It seemed to make little difference on the PC what they said, numerically. I edited the steps per rotation (on the PC), quite a bit, for zero difference in the lasered product…

The only places things changed were the U axis calibration in vendor settings, and User rotary steps per rev. on the console.

yet the console was not using the U output - once I unplugged the Y plug and put it in the Y socket, then the U + and - keys failed to do anything, but the Y keys made it rotate.

I am totally stumped as to how to get the controller to send the rotary instructions to the U part of the controller. Having to use the Y socket defeats the reason I bought the 6445 in the first place.

I’d love to hear from anyone who’s been here and solved it, thanks!

I could not find a newer firmware file to update from 26.01.19, in case that was the problem.

I did check the [use U for rotary] in User settings. What more could I do? There’s a “use rotary” option to check in layer parameters,-advanced- but that seemed irrelevant. I mean checking or unchecking it, did nothing different from the other.

The rotary works- but only after I set Y to operate in reverse in vendor settings, and use the Y socket to control the U drive.

It’s all a bit exasperating… as well as the time wasted/spent trying to see what edits have no effect, and what ones do.

(I’d just like to have it working the way it is supposed to. I got the 6445-S from Cloudray.) I read here the firmware version 26.01.13 works with U, but I could not find it to download, and backwards-apply - if that’s safe. I could not even find the 26.01.19 version that’s currently on it, as a download.

Thanks for any suggestions!

This may be related to the firmware revision. It seems newer firmware revisions allow you to select U vs Y for rotary.

However, if you want to default to U for rotary then you may want to consider firmware version 26.01.13.

Check out these Topics for more information:

Thanks for replying - I’d read all that - oddly yesterday I could not download those firmware files (via Firefox), but I copied the link into that ‘edge’ browser of MS (ugh!), and it let me download them… weird!

I could apply the version 13, but I’d really like to know where a spare copy of 26 is - that’s on it now, before I wipe that out…

Aren’t you on 19 now?

One of the posts links to a Google Drive folder from another user that includes it:
RDC 6445 firmware - Google Drive

Oops, yes - we’re on 19 now.
MANY thanks for that extra upload.
I’ll try tomorrow - AFTER I manage to get the Controller to connect happily with the PC via the LAN…
There’s no logic in why it wont - it used to, then got worse then stopped. I remember I had t assign a static IP address to the PC. (P.S. that PC is Win 7, and not connected to the internet - which is how I like it!)

Many thanks for the reply
Ian

Good luck. I’d suggest taking a backup of your current configuration before applying the upgrade in case things go sideways.

1 Like

Yes, I’m used to that - but photographing the screens is the next best option, when they won’t talk to each other…

That PDF file you had is interesting, saying to NOT check the backlash checkbox under config meny, if you are using the backlash figures in the user menu.
And similarly saying to not check two boxes above the reverse interval compensation figures.
It makes you wonder why they offer the extra boxes then?

A hard backup is a fine solution.

Note that the Google Drive is not mine. I did notice a service bulletin about backlash but didn’t read it. I saw these as advisories about how to deal with specific issues that might be experienced.

I used to plug directly into the Ethernet on my Linux box… Had to configure it, similar to yours.

I’m pretty confident you don’t have something correct in the Ethernet configuration on the pc…

Need to static and in the same domain. I set my pc address to the gateway address on the Ruida. I don’t think it needs to be on the gateway, since it’s a static device, but worked well until I moved to a wireless bridge.

When you plug this in, does the Ruida show a lan connection on the console? This only indicates the hardware is connected but it’s a good starting place.

:smile_cat:

Thanks for the reply, Jack.
Whether I plug the 40 ft LAN lead from the PC into the RD6445, or into the laser socket beside the console (after changing the controller plug), or if I use a wireless receiver and plug that in, the RD controller LED12 lights up, so that end is ok.
Ditto when I had the 6442-S in - still wouldn’t talk.

I have a device for testing network leads- you plug it in one end, plug the return receiver in the other end, and turn the power on, and if all 8 or 12 LEDs light up in stepped sequence on both ends, one second apart, the lead is fine. It is.

I put a fresh PCI express LAN port on the PC. It installed ok.
Wifi works.
The PC can find the Wifi receiver if I plug that into the laser, too.

Therefore I must have something poorly configured with the addresses - I remember it was a painful process 5 years ago getting it right, then it started to play up on its own, 18 months ago.

I may try just plugging a laptop into the controller via a short LAN, and doing the Frmware back-date that way.

My notes on the original solution were simply that I had to assign a static IP address to the PC… but so far that’s not been sufficient, this week.

Those 2 service bulletins were good reading - better than the instruction book.
I wonder where they came from originally? It’s be good reference material to have more of them…
But I find them still a bit weird.

I only have a 6442, but the Ethernet setup should be the same.

Did you change the Ruida IP or use the original 10.0.3.3 that is the default?

If you use the original, you need to be addressed on the domain of 10.0.3.x

:smile_cat:

192.168.2.50
from memory, for the RD controller

I’m heading back to the workshop in a moment to try again.

Yay! At last the PC and the laser will connect, via LAN, and the wireless version of it too, after somehow getting the static IP to stick to the PC

BUT the RD controller will not let itself be downgraded back to firmware version 13, from 19.
I tried twice, and got the blue dots as if it was working, then a ‘failed’ message.

Is there maybe a v.26.01.20 for firmware?
Or maybe if I tried 16, and then 13, so it was doing smaller backward leaps than 19 to 13?

Update:
I can drive the laser via Wifi now, from the PC.
I cna use the test buttons on the PC, to make the rotary go round and back - just as I can by pressing U= or U- on the console panel of the RD 6445-S.

BUT no amount of telling the machine that U is the rotary axis, turn rotary on at the PC, turn rotary on at the console, etc, will make a file rotate via the U plug.
But the U button works.

In order to laser, I have to unplug the Y plug from the controller, and plug the rotary’s plug into where Y was, instead of the U socket.

It would be wonderful to figure out why it won’t turn from a sent RD file, but will from the buttons, and will from the Y socket on the controller…I’m at a loss for answers!

(It would not let me backwards /downgrade the firmware to v.13)

I recall seeing that a newer firmware revision might also work. Did you thoroughly review the other posts to see if there was anything like that?

Surprised you’d have an issue downgrading firmware so that’s odd.

Thanks for the reply - yes, I’ve thoroughly trudged the internet for solutions… to no avail.
If I could locate a version of the firmware that’s newer than the 26.01.19 on it, I’d certainly give it a try.

I’ve just had another thought that I figured might be worth mentioning - in case the v19 firmware is actually somehow damaged, and that’s to try & reinstall the same version 19 firmware over itself… now that I’ve been able to download that version as a spare.

Might be worth a try. Curious if that could also resolve the ability to downgrade the firmware.

Well… good news!
I was able to update the firmware with the same 26.01.19 over the top of the existing one, then reset the machine, then downgrade it to version 13, reset, and the rotary now works via the U drive. (In hindsight, maybe I should have retested it in v19, before downgrading it,)
but the main thing is it is working!

Just have to calibrate it to our double rollers now…

Many thanks, All!

1 Like

That’s fantastic. It does make me think that there may have been something wrong with the existing flash and that it indeed should have worked with the original firmware version. Curious.