Uploade using Onefinity web UI from remote device

My preferred method for interacting with my Onefinity X50 is from a remote device instead of a connected display device. My Onefinity is connected to my local network, and all of this works perfectly fine … for the most part.

The one odd issue is that if I want to select a gcode file to process by clicking the folder icon button in the UI, it works fine if I am working from a Chrome browser on my remote laptop. So from chrome, i connect to the onefinity IP address, it displays the UI, and I can completely control the machine and upload new gcode files perfectly fine.

However, if I do the exact same steps from an iPad or iPhone, the upload gcode button does not work properly. When you click the upload button, it tries to find the gcode files on the device that is running the web page - in this case an iPad or iPhone. I can browse around folders and see files, but I can not select a file to upload.

I saw a suggestion around changing file extension / types to ‘.txt’ - but that doesn’t seem to work either.

Seems like it is most likely a simple coding issue on the webUI, but I wonder if others have noticed this, or fixed it ?

Hey Mike,

but you don’t describe a different behaviour between laptop and iP*thing: The browser opens an “Open file…” dialog on the machine it runs on. The question is, where on the filesystem hierarchy are you on the iP*? Can you access the directory where you have your g-code files?

On laptop, the open dialog works exactly as expected. I can select files and upload them. on the iPhone / iPad I can browse folders, i can see files (they are actually kinda "greyed out"O but I can’t select them.

And you have .nc or .ngc files there?

Yes. And I see the files - but they are not selectable. I tend to store the files in “iCloud” so the folders appear on iPad there. But I also tried it with files loaded directly on the iPhone local storage with same results.

Hey Mike,

sorry that I can’t help you. But it seems to me that I remember that someone already reported such an issue. I would try to search for it with the search function. It could well be a non-Onefinity issue but a iP* issue or a chrome issue. Did you try another web browser?

PS: The browser that the UI was written for is a (very old) version of chrome

1 Like

Tried in Safari and same result. I had entered a discussion before, but wanted to try and log the issue clearly for future consideration.
Thanks.

Hey Mike,

can you get access to the local file system with other “websites” (on the iP* device)? E.g. here, in your message composition window, can you click the “Uplaod” icon (the seventy from the left in the top row) and select a file to upload? If not, then it would not be Onefinity-UI related.

It could be a security option to first allow access by a web page to the filesystem on the local machine.

Yes. Able to attach file here for example from iPhone

v2_toolpath1_profile_25upcut.ngc (14.7 KB)

Hey Mike,

at first sight, I cannot see something in the markup that would make a difference between different platforms. The page that is served by the Onefinity Controller Web Server is

/usr/local/lib/python3.5/dist-packages/bbctrl-1.0.9-py3.5.egg/bbctrl/http/index.html

What is an obvious difference, is that the page served by the controller lacks https encryption. Nowadays many browsers exclude such pages, or you have to manually allow visiting the page. I have no experience with Apple products, but could it be that some security option prevents uploading files from your local system through an unencrypted connection?

“Greyed out” files in your local file upload window would mean that you are not allowed to read or select them for some reason.

It is difficult for me to imagine how this could be related to the Onefinity UI page, i.e. something in the page that alters its behaviour when you use an Apple iP* device. I would rather think that it is something that is caused locally on your device, since the same Onefinity UI page works when you use the laptop. But I cannot be sure.

Reasonable assumption. I have set up ssl before, i might be able to give it a try. It is a bit of a pain to generate a legit cert, but i might have a way.

Aha ! I went into the index.html and removed the ‘accept’ parameter and it works ! So it has to do with how this is implemented. So I changed

<form class="gcode-file-input file-upload">
                  <input type="file" @change="upload" :disabled="!is_ready" accept=".nc,.ngc,.gcode,.gc">

to

<form class="gcode-file-input file-upload">
                  <input type="file" @change="upload" :disabled="!is_ready" >

So of course now it doesn’t prevent me from trying to upload the wrong file type, but it does make the file selection work on web and mobile (iPhone/iPad) on both Chrome and Safari.

Hacky workaround, but it does work.

3 Likes

Doesn’t Apple use a different file formatting system for the Mac/iPad/etc OSes? That would explain why the .nc/.ngc/.gcode/etc restriction on the accept parameter wouldn’t work as expected. Those work with Windows but OSX would need a different set of filters.

Hey Mike,

glad to hear that you found a solution. But I would not have assumed it there. I knew of the restriction to these file types in the form, but why was everything greyed out then? Would this not prevent the .nc, .ngc, .gcode, .gc file endings being greyed out?

I don’t think the filetypes are .nc or .ngc in the Apple file system. So, the accept parameter doesn’t find any files that match and thus greys everything out.

I suspect the “right way” is to use mime types there instead of file extensions. I just haven’t yet looked up the correct mime types in the web server.

Hey Jim,

obviously there was no match when Mike used a iOS device. Did not think that the file restriction does not work on devices with iOS.

Does this way of restricting files also fail on Max OS X?

It works on mac, just not iOS

Doesn’t iOS use APFS? That may be the issue. Or the iOS browser’s support for the “accept” HTML parameter may not read the underlying filetypes correctly.

Yeah, that is why I suspect if the correct files have mime types defined, then you may be able to use mime types in the accept clause and it should be more cross platform compatible. I will give it a try tomorrow

1 Like