Hi.
Our 3L is in our lab which has swipe card access. The printer is on our company network. We have a team in the formlabs dashboard of 12 people who are the rightful users of the printer.
I assumed that remote printing to our printer would only be allowed for those team members. However, I’ve discovered that if you have PreForm and you’re on the company network you can see the printer and send prints to it without being logged in.
And so every now and then I’ll go to print and find that “unknown” has printed something on the printer, which means the printer can’t no accept another job and requires someone to go in, remove the print and reprime for the next job. With remote working sometimes you might not be in the lab very often and want to be able to work on a print remotely, send it to the printer, and only go in when it is complete.
Sometimes this happens in error, sometimes somebody trying to be “helpful”, sometimes someone trying to get a sneaky print done.
So I’d like if you could restrict use of remote printing to team members only (I understand someone in the lab could plug in their laptop and start a print, but as I said, the lab has card access).
Further I’d like at times if prints could be added to the queue by the team, but only an admin can start the print. Maybe the admin gets a mail when prints have been added to the queue.
Your IT team can probably limit access to the printer on the network to only authorized users. I think this is generally described as “Network Access Control” - limiting access to resources on a private network based on some criteria. Like a firewall policy on company clients that block access to the printer’s IP… probably a bunch of different ways to accomplish the same thing.
You could also do it with a network bridge, of the type that provides user access control, with the printer behind the bridge.
Hi Randy.
Yes, you would think that access control would be achievable, but in our very large company getting any kind of change to global setup is phenomenally difficult. Personally I think figuring out with people how to make networks as useful as possible should be a fundamental work package for any IT team, and that it would be more interesting that some of the mundane tasks, but it remains enormously, frustratingly difficult. I’ve had those conversations to no avail.
The network bridge might be a better approach, but it remains that it would be another thing for us to maintain, add users, remove users, problem solve, etc, etc.
For me it seems the elegant solution with the dashboard already having groups and printers assigned to those groups would be a means to control remote printing at that team level. It would mean we could leave the network alone, not require an additional network bridge, an still maintain printer access.
But since there’s no top-level driver/queue that printing requests go through before being sent to the printer, all that access control would have to be implemented on the printer itself. That’s a heavy lift. I would be surprised if FL would be willing to commit to that, and if they did, if they could deliver the functionality in less time than it’d take for you to find some alternate solution. Assuming the printer even has the memory required to support the additional functionality, you’re looking at a long wait if they’re willing to commit at all.
I don’t speak for FL, of course, but IMO you’re going to need an alternate solution.
Hi all,
As far as I know, we do not have a baked in solution for what you are asking at this time. You can submit feedback to help get more eyes on this via the Help Menu in PreForm and Give Feedback.
A personal alternative solution is to have the printer on a network separate from the company network as a way to limit who is able to use the printer, although this would not be the elegant solution you are looking for - hope this helps in some capacity.
We do look at this feedback and we appreciate you sharing your thoughts with us.
Hi Randy.
I’m thinking of no changes to the printer…there’s a much easier way.
In Preform it currently doesn’t require you to log in to send a job. If you have the, let’s call it “restrict remote printing to team” option set for the printer on the dashboard (1 additional databse entry for the printer), it would require you to log in before you can send a job to that printer. On log in it checks if you are in the same group as the printer is assigned to (all this info is already captured in your account) and only sends the job from Preform if you are within that group.
No changes to the printer, small change to printer info in the cloud database, small piece of additional code in Preform.
Thanks for getting back Phil.
Yeah, we looked into getting the printer on a seperate network…no joy. They are very rigid on what they’ll do around networking and any change from the norm is an enourmous ask…very frustarting as we build rigs that we would like to access over the network for programming, data access, etc and we can’t…ridiculous. But that’s a fight I’m fighting continuously.
Thought I’d throw the concept in for the record anyway.
As an alternative, if you can figure out who’s sending jobs to the printer that isn’t supposed to, you could pour a little liquid resin on their desk as a warning not to repeat that behavior.
If the printer is in an access-only room, and there is an unknown guy printing behind your back, then how is he getting inside the room to get his print?
Best option if for a dashboard option to approve or decline the prints, then it’s to find that guy and ask him not to print again.
Even though there’s swipekey access, it’s still a busy lab and people without cards often have to get in there for one reason or another. Not ideal unfortunately I know.
You could use a cheap server such as a Raspberry Pi running Linux as a print server. Only people who have access to the Server would be able to print. There are lots of Open Source Print servers available probably the best known is CUPS OpenPrinting CUPS
Actually this printer access feature exists on Cura and Ultimater printers, you can set approvals for items sent to print, or decline them, or set up guests authorised to print. I’m sure Form’s guys have used Cura in the past so more or less they should know this feature
That’s interesting. It really seems like a featue that should be present.
The problem has since got more frustrating, because another group in the building now have a Form 3 which is more or less open access to everyone. So they:
go into preform
see 2 printers listed
the printer names are the original, Formlabs assigned, fixed, non-descriptive names and there is no way to add a description of which lab each pinter is in to the dashboard or PreForm list
if no-one is around to ask, they make a guess
nothing alerts them to the fact they aren’t one of the assigned users to the group that printer is in
print ends up sent to our printer instead of the “open access” printer
I just find it so very odd that the current setup of assigning a printer to a group and assigning a list of people to that group has no actual effect on access. Just seems like that last piece was forgotten.
This really does need to be an added feature. At the minimum adding a setting to the machines to require a logged in user and no guest printing would be wonderful. I often times have to try and track down who printed something if the print failed or they sent it without coming to change out the cartridge and tank and the print will just sit in limbo. We would love to be able to restrict access to the user group we created on the dashboard which would then require everyone in the company to create an account and request access to the group in order to print something.
I greatly appreciate your input on this. I’ve gone ahead and shared your feedback with the team - I agree that this would certainly be useful in terms of providing more control over who is able to use printers in a shared workspace.
We have an almost identical situation as @stephenf555 (in fact I thought I had written the post). Having a way to restrict prints to a “certified use group” would help a lot.
We are working on implementing the restricted network solution that your support team has mentioned, but ideally this would be controllable at a machine or dashboard level.
thanks for pushing this idea to the dev team.
-ryan
