search

winder / Universal-G-Code-Sender

A cross-platform G-Code sender for GRBL, Smoothieware, TinyG and G2core.
http://winder.github.io/ugs_website/
GNU General Public License v3.0
1.88k stars 762 forks source link

Latest UGS Platform 2.0 nightly keeps lock on currently opened gcode file, cannot edit externally #1197

Open shredEngineer opened 5 years ago

shredEngineer commented 5 years ago

When a gcode file is opened in UGS, most of the time it cannot be edited by an external editor anymore.

Feature request

Problem description

Expected Behavior

Actual Behavior

Steps to Reproduce the Problem

1. 1. 1.

Specifications

Version

UGS Plattform 2.0 nightly

Operating system

Windows 10 Professional 64 Bit

Platform

GRBL

Other

breiler commented 5 years ago

Are you running Windows?

shredEngineer commented 5 years ago

Yes. (Added to issue, sorry I forgot)

AbySet commented 5 years ago

When a file is used in some process, it can not be changed in another process, this is normal behaviour, you should close the first process first or close that file in it. This brings the idea that UGS is not closed or file is not closed in UGS even if it does seem to. Check it in task manager.

shredEngineer commented 5 years ago

I strongly disagree. I don't need to "check the task manager" -- UGS platform is open, and so is my external editor of choice. Thats the point! Upon opening any (gcode) file, UGS platform should open the file, buffer its contents to memory (don't tell me there's not enough of it on today's systems) and then CLOSE the file, thus releasing any locks on that file. The file should be editable externally at any time.

The primary reason I'd find this useful is to visualize any manual changes immediately or at least without resorting to a new filename (which clutters my folder) or, even worse, restarting UGS platform completely. Therefore, optionally, an OS "file changed" handler may be registered which notifies the user about the changed file and offers a reload option. Additionally or alternatively, a simple reload action may be offered in the file menu.

ALSO, to make things even worse, UGS platfrom currently does NOT even release previously opened files during the same session, even if another gcode file has been loaded. Now this really doesn't make any sense to me. E.g.: Open "A.gcode", then open "B.gcode", then open "C.gcode". Now none of these files can be edited externally anymore (at least most of the time ... like I stated in the issue) while UGS platform is running. I don't think this is intended behavior.

Thanks for considering!

AbySet commented 5 years ago

I said (it can not be changed) not (it can not be opened) this make difference.

breiler commented 5 years ago

@shredEngineer I agree with you that this shouldn't be the intended behaviour and that we could do this in a more modern approach as you describe. But we may be limited by the NetBeans platform.

I need to investigate this a bit so it's not our custom code that locks the file. It might be a bit problematic to reproduce the error in Mac or Linux (which is the OS:es that I have available) though. I'll see what I can do.

JacksCrafts commented 5 years ago

I have never had a problem with this. I use Aspire and have many times changed a project, while UGS has it up. I just hit open, select the same file again and it refreshes to the changed file.

Product Version: Universal Gcode Platform 2.0 [nightly] / Dec 18, 2018 Java: 1.8.0_201; Java HotSpot(TM) 64-Bit Server VM 25.201-b09 Runtime: Java(TM) SE Runtime Environment 1.8.0_201-b09 System: Windows 10 version 10.0 running on amd64; Cp1252; en_US (ugsplatform) User directory: C:\Users\jacks\AppData\Roaming.ugsplatform\2.0-SNAPSHOT\dev Cache directory: C:\Users\jacks\AppData\Roaming.ugsplatform\2.0-SNAPSHOT\dev\var\cache

breiler commented 4 years ago

This is a problem in Linux and Mac as well. It seems that we don't close file stream in multiple locations in the software. Opening a file with the visualizer enabled, three file streams are opened and never closed. Each time we send a file a file stream is opened and never closed. So this is a general problem that we need to look into.

Listing open files can be done using: lsof | grep <filename>

Anacapala commented 4 years ago

If it is too difficult to close the files automatically, then provide an option in the File menu so that the user can close the file.

I run a workflow where the gcode is created by another application that assigns a file name automatically using the next available numeric suffix. I need to delete the old version before creating the new one so that the same suffix is re-used and I can simply Reload.