Communicating with Ruida controller for user restriction

Not sure how to phrase this as a new post or a new topic, but I am part of a 501(c)(3) volunteer managed makerspace that recently acquired a BOSS LS1630 which uses the Ruida 6445S controller. We are trying to develop a system to restrict access to members who have completed the safety class and to log (and hopefully one day charge) for actual use. The access restriction is not difficult via hardware, but I am in the process of writing code to query the controller over our network, using the UDP messaging, for run times and other parameters. I’m having trouble finding reference material for the commands and replies that the controller understands and provides (respectively). I am comfortable with a number of languages (planning to use python for the project if practical). Do you have any suggestions where to look for this information?

Without having context of the problem set can I ask why you’re trying to do this at the controller level?

Would it not be adequate and simpler to control/monitor/track usage at the workstation level? You could maybe even do this with domain controller policy for basic authentication and authorization.

We already have an RFID-based access system in place for the building itself and when it was designed, it incorporated future expansion to allow restricting access to specific equipment (i.e. table saw won’t operate if you haven’t been woodshop certified, laser won’t operate, etc.). This would allow a single access point for managing access in general.
Because of our physical setup, there is no way to ensure that individuals are going to use the nearby, USB connected computer workstation to run their jobs from, thereby defeating any tracking system that relies on the workstation. They may opt to use a laptop or simply transfer an RD file via the USB port (unless we choose to unplug it, which I don’t foresee). I have seen a number of makerspaces who have used microcontrollers to periodically poll the status pin on the controller, but then they need to continually recalculate and update a local variable for the job time. I’d rather simply ask the controller itself before and after a job, since it’s already managing that data, and make one set of calculations to determine the cost/charge from a job.
Since Python-based UDP messaging is actually very simple to code (and can run in parallel to our shop access system) it seemed like a logical solution.

Very interesting problem scenario.

I still tend to think that querying the controller won’t be very productive. Do you have an idea of what signature you’d be looking for in the controller? I think you’d have better luck controlling the “gates” to the controller if you’re going down this path. Perhaps some sort of NFC enabled USB port that you cover the existing port with. The NFC verification being tied to the shop access system.

For network access you could check for all UDP traffic to the controller. I assume the users need to be authorized to your network so you could validate source of UDP traffic and charge accordingly. If you want to really reverse engineer the RD file perhaps charge based on overall laser time or laser distance travelled.

There are RE efforts documented online already that could probably get you at least the minimum required to do this.

The RFID/NFC reader is already going to be attached to a microcontroller that can enable or disable the laser from firing by holding the LaserOn pin to ground or 5V via a relay based on the users equipment permissions. When they scan their RFID, I also want to be able to see the current laser and project ‘odometers’ (for lack of a better term) and check them again after they sign out. I definitely don’t want to re-interpret RD files to try to assess what the file’s project used in resources.

I simply want to mimic the call that Lightburn makes to the controller for the “Get Controller Info” call to read the current project and laser times to see how they’ve changed over time.

Got you. Your solution is already fairly sophisticated.

Instead of dipping into the controller for this how about connecting some sort of addressable smart power meter. Maybe even part of the same solution as the dead switch microcontroller solution. A power meter would be a fairly consistent measure of usage.

Or is getting the specific named project files significant? Which by the way may be a reused temporary file name. Trying to think of a natural “odometer” on the controller side… check this link from Rick. He talks about some of what’s in the controller. Don’t know if these can be queried.

You should review this thread for more general information. I don’t think it would be particularly difficult to query the controller for some basic information although there’s some obfuscation going on in the communication layer from what I recall.

Thanks for the thread suggestions. The “System Info” values are exactly what (I think) I need to do the usage calculations. I don’t think I’m super worried about the work file name.
I’ll take a closer look at those 2 threads.

Hello Dan,

Similar situation here. I have a system controller here that handles simple system tasks outside the Ruida. ATMEGA2560 DIN breakout board and a spaghetti nightmare I will soon replace with a manufactured PCB. It’s had a Command Line Interface which allows me to defeat the door interlock and moonlight the laser to make alignment way easier and more accurate than that dumb pulse-on-tape stuff. Plus, modbus and ethernet leave a lot of room to experiment with new concepts.

When you say ask the controller, are you looking to do the same query that LB does if open its file panel to check the Ruida for what files it has and their runtimes? I have had this hang the Ruida on just common small rasters, at least it was taking so long and couldn’t be aborted that I gave up and cycled power. If that’s ever true for any sort of legal file, this can’t be a required step to pre-bill, I was envisioning a login and just logging minutes used for billing purposes. It would be up to the user to use Preview to estimate the time, and it sometimes takes substantially longer than the estimate for very fine detail vectors. But that’s just something they have to take into account.

What about the RTLink? I have exactly zero documentation on that. It has 3 pins are there is a type of supply that it can communicate with, and more importantly a remote- and the remote’s doc clued in that this is an RS232 interface, but I have not seen even any info from anyone trying to capture the traffic.

One thing that came to mind is, they would have reused the commands we already know from the PC link, formatted as UART serial. And they might have not limited it to respond to “A5” commands for the panel arrows, it may respond to any command- perhaps wishful thinking, but it would be simplest to just treat it the same as the ethernet link’s communication and reuse code.

LOL I thought about that, it’s possible to do. We can already bill by “controller on” time or just “seconds the laser is actually running (STATUS pin)”, but also, yes, you can bill by supply power. Because when you fire a glass tube, going for whatever duty is deemed the “full power” continuously to cut wood or acrylic does generally wear the tube faster per hour than lightly engraving the surface or rastering. So it does make some sense. But, also, the system controller I put on back of the Ruida can already watch the laser control pins and integrate the % power requested over time. Pretty token code to just poll analog control with an ADC or put the PWM through an RC filter and then to the ADC.

TBH I’m not really excited by the concept of time billing, I look to make things MORE freely available. But, I do like to invent new things.

I don’t know if I’ve followed everything you want to do here but maybe what I’m working on might help.

One is that you could have a micro detect the rfid and though one of the ssr switch the whole machines power. No proper id, no power. That same micro could watch the ‘status’ pin for timing.

Your idea of L-ON1 would still allow the laser to run, but without the laser firing. The mechanical ‘go rounds’ would be working.

The other is, I run the ‘Status’ and ‘Wind’ lines to a micro. This allows me to set the state of either line manually and the ‘touch’ display allows me to ‘modify’ the buttons without drilling more holes in the box. It has mosfets that control the solenoids. Essentially sits between the controller and the air solenoids.

I found the KISS principle seems to work best…

Do you have any idea how ‘actively’ the Ruida responds to udp requests? There is no error protocol in udp as far as I know…

Seems to me when I been fooling with it and you ‘run’ something, seems like it totally ignores the Ethernet port.

Watched it a bit with wireshark…

Keep us updated :crazy_face:


I would just plan on opening the door interlock. Cutting off the main power is not a very graceful way to operate, especially on the powering-down side.

It also depends on how you want to bill. Chair time, cutting time, or cutting power-time? We already require a calendar system to reserve time. It would be most logical to handle chair time billing at that level. The laser can query whatever bookkeeping database you have and refuse to run if the clock time is not reserved for that user.

Cutting time would be by STATUS pin. Cutting power-time would be integrating the PWM or analog Ruida command.

There’s a question of what’s best to do if this exceeds their usage. It can be inadvertent, jobs often take longer than intended. I thought about it a long time and am uncomfortable with cutting off a running job at all as a method. It ruins their work and seems spiteful. Cutting mains mid-cut is just a bad idea for the system over just opening the door interlock, though.

It is also a question of whether you’re billing as a credit or debit account system. Debit would be prepaid minutes like a prepaid cell phone. Credit would just bill for whatever you use at the end of the month, which has little reason to be stopping the user. If you do a debit system, you’d either have to cut them off or also be able to issue additional time on credit, which seems to make the debit billing system pointless as it would have to be both a debit and credit billing at that point.

I think the ideal is using the door interlock to allow the machine to be inspected and practiced with, but not actual cutting without billing. The system can deny access for starting a job, but will not stop a job in progress.

At worst, there’s a case where a user starts a job when they do not have enough amount of time left. Maybe they don’t have the money and are trying to “game” the system, I prefer not to judge. This isn’t possible with a credit system, but is with a prepaid debit system. I prefer a credit system for this reason. The amount of “overdraft” time you could do seems limited, even if your system has no ability to run up a line of credit for the overdraft time. Individual jobs can only run for so long until you need to swap sheets or send more data and it can cleanly stop you at that point.

I still think it’s a bad idea to interrupt a user’s running job over a billing system issue. Esp since it’s not uncommon to have errors that are on our side- or, well, at least not intentional. Plenty of people have not had their door access work right away because they signed up with a different email or other such detail.

This would be a sure fire way of building user resentment and eventually losing your user base.

You could deter people from trying to “sneak-in” a long cut at the end of their time by introducing a surcharge or weighted charge for over-time cuts. Just make it transparent and fair but painful enough where people will want to avoid it. Frankly, I think this is only a real problem if they’re intruding into someone else’s reserved time. So maybe only apply the surcharge under those conditions.

Actually I wasn’t thinking about killing the power mid run, just using it to associate the use to a certain user… I think both of you are right, you don’t want to interrupt a job mid stream definitely ‘PO’ people…


But if you can do after-the-fact billing at all, why have a prepaid system to begin with? You just bill for use at the end of the month. I can already guess there will be users who didn’t read even the “large print” part of this and didn’t realize how much billing they were accruing. It’s slightly less awkward if they went to the online store and paid $ for 30 minutes of cutting time and were surprised at how fast they blew through them. It’s harder to argue something was unclear or unfair.

But I can totally predict that like half a dozen users are going to send angry emails after accruing a bunch of laser time and seeing the bill at the end of the month. I don’t want to simply gloat about denying ignorant members who don’t read fine print, rather, I’d regret losing them and I’d regret leaving the capacity open for that sort of argument that creates bad blood. Both systems have advantages and drawbacks

Sorry. I wasn’t even directly addressing the pre-pay vs post-pay component but mainly about how such behavior could be mitigated. Also, I think there’s value in separating payment terms vs whether or not you allow for a negative balance. Meaning you could have an 'in advance" payment process but still allow people to go over their current allotment. From a purely technical perspective as you say if you have to solve for the in arrears scenario then you’ve already solved for the hard part but there are business reasons why in advance might be beneficial. The main ones being you’re not having to front the costs of running the laser and will run into fewer collections scenarios.

Whether or not this makes sense will depend on a lot of factors, one major factor being if you see charges as purely quantified or whether or not you’d want an all-you-can eat type of model which I could see being attractive to regular users.

Don’t disagree. In general I’d personally steer toward more consumer friendly policies and only try to correct for abusive behaviors.

Since we haven’t even managed proof of concept yet, we aren’t bound to one plan. My own preference is somewhat of a hybrid to what @berainlb and @Dannym are suggesting: set users up with a pre-paid balance and bill any excesses monthly with the caveat that major negative balances will (just because the system won’t allow it) result in the machine not working.
We are also looking at maximum hours of time reserved so that one user isn’t just hogging the system even if they’re not actually using it.

A brief update: Using the Meerk40t Ruida emulator, I have managed to cobble together some python code which (I believe) can collect a variety of data components from the controller of our BOSS1630 (at least it works on the emulator, I won’t have access to the actual device until Tuesday). Fingers crossed. :crossed_fingers:t3:

Nice. Would be great if you could share your solution here.

As soon as I prove to myself that it works with the real thing. :grin: