Page 7 of 20
Re: KISSlicer 1.5 Beta 2 - in development
Posted: 19 Feb 2015, 00:58
by lonesock
Found the "no INI file crash" bug. I just posted a 1.5 beta 2.16 build (Windows and Mac, I will try to get Linux up tomorrow). Not much has changed beyond that one bug fix.
thanks,
Jonathan
Re: KISSlicer 1.5 Beta 2 - in development
Posted: 19 Feb 2015, 09:14
by mhackney
Great, thanks. KAS on SeeMeCNC forum discovered this and I directed him here.
I also noticed with both this and the new 2.15 that when I launch the first time I get a "File not found" dialog. This is simply by double clicking the app in Finder (yes, Mac) to launch it. Not a big issue but maybe another buglet in there.
Re: KISSlicer 1.5 Beta 2 - in development
Posted: 19 Feb 2015, 10:01
by kas
Both 32/64 bit appears to work great on Windows 7, 8 and 10 with creating new .ini files. Thank you for the quick fix.
Re: KISSlicer 1.5 Beta 2 - in development
Posted: 21 Feb 2015, 15:00
by kas
Just a quick update, 1.5 Beta 2.16 64 bit occasionally causes fault and forces auto reboot on Win8, this happen about 5-8 seconds after clicking the Slice button.
32bit doesn't appear to cause the same issue for me.
Error from event viewer.
Code: Select all
Faulting application name: KISSlicer64.exe, version: 0.0.0.0, time stamp: 0x54e57a2d
Faulting module name: ntdll.dll, version: 6.3.9600.17630, time stamp: 0x54b0e17a
Exception code: 0xc0000005
Fault offset: 0x000000000001f0b2
Faulting process id: 0x1968
Faulting application start time: 0x01d04e0f16399569
Faulting application path: C:\Users\Kevin\Desktop\KISSlicer_Win64_1.5beta2.16\KISSlicer64.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: 543aa5c4-ba02-11e4-826f-94de80a7c247
Faulting package full name:
Faulting package-relative application ID:
Re: KISSlicer 1.5 Beta 2 - in development
Posted: 23 Feb 2015, 12:44
by lonesock
I just posted the Linux builds to the Dropbox folder. Please keep up any bug reporting!
@kas: Weird! I haven't seen that, and a fault in the ntdll.dll is a bit strange as well. Is there any chance it could be hardware related, specifically RAM? If you increase the oversample resolution (from the default 0.125 mm to maybe .5 mm), or reduce the slicing thread count (under the [Misc.] tab), does the problem go away, or happen later? (You can also watch the used RAM with the task manager and see if the issue happens at a specific threshold.) Sorry, I am just grasping at straws on this one!
Jonathan
Re: KISSlicer 1.5 Beta 2 - in development
Posted: 23 Feb 2015, 18:54
by kas
No problem. I'll try to tax the system with different STL's and see what I can catch. I'm running an 8 core system with 32 gigs of ram.
I'm not a programmer by any means, is it normal for a 64bit program to access the .dll's in system32?
I would think C:/Windows\SysWOW64\ntdll.dll for 64bit. but again I have no clue.
Re: KISSlicer 1.5 Beta 2 - in development
Posted: 23 Feb 2015, 20:15
by kas
Re: KISSlicer 1.5 Beta 2 - in development
Posted: 23 Feb 2015, 23:48
by PenskeGuy
lonesock wrote:@kas: Weird! I haven't seen that, and a fault in the ntdll.dll is a bit strange as well.
Not weird. I've had a number of crashes in various versions with ntdll.dll showing a fault and posted many times about it. Of course, that was on the original forum.
Re: KISSlicer 1.5 Beta 2 - in development
Posted: 24 Feb 2015, 05:53
by Beefi
Hi Jonathan,
I'm new here in the Forum. In comparison to other slicers, KISSlicer is the best solution for me. I love it!
A short time ago, I tested the feature "volumetric printing in cubic millimeters" and "firmware retraction" of Marlin Firmware (with Slic3r).
I'm surprised of the enhanced Quality by using this features.
Would it be possible to implement it in KISSlicer?
To retract/recover you only have to send the G10 (suck) and G11 (prime) command to the Printer instead of retract by G1-command.
Auto-Retraction in Marlin Firmware doesn't work.
Andi
Re: KISSlicer 1.5 Beta 2 - in development
Posted: 26 Feb 2015, 14:01
by swsch
Beefi wrote:"firmware retraction" of Marlin Firmware
- Printer -> Firmware -> Mark Path Start/Stop -> G10/1
- Material (Matl) -> Destring -> Prime 0, Suck 0
gives gcode like the following:
Code: Select all
; 'Prime Pillar Path', 0.4 [feed mm/s], 20.0 [head mm/s]
G1 X3.69 Y29 Z0.2 E0 F15000
; trigger prime
G11
G1 X3.79 Y27.5 E0.0295 F1200
G1 X4.43 Y25.04 E0.0793
...
G1 X3.69 Y29 E3.7189
; trigger retract
G10
;
; 'Destring/Wipe/Jump Path', 0.0 [feed mm/s], 20.0 [head mm/s]
G1 X3.79 Y27.5 E3.7189
G1 X4.43 Y25.04 E3.7189
G1 X5.55 Y21.66 E3.7189
G1 X6.5 Y19.77 E3.7189
;
; 'Loop Path', 0.3 [feed mm/s], 20.0 [head mm/s]
G1 X7.31 Y32.01 E3.7189 F15000
; trigger prime
G11
G1 X7.59 Y28.97 E3.7667 F1200
G1 X8.31 Y25.76 E3.8183
So paths are wrapped by G11 and G10 and there is no G1-based sucking or priming.
Setting prime and suck to non-zero values results in the following gcode, where you can see the retraction at the beginning of the destring path and the priming at the second line of the loop path
Code: Select all
...
G1 X3.69 Y29 E6.2689
; trigger retract
G10
;
; 'Destring/Wipe/Jump Path', 0.0 [feed mm/s], 20.0 [head mm/s]
G1 E3.7689 F900
G1 X3.79 Y27.5 E3.7689 F1200
G1 X4.43 Y25.04 E3.7689
G1 X5.55 Y21.66 E3.7689
G1 X6.5 Y19.77 E3.7689
;
; 'Loop Path', 0.3 [feed mm/s], 20.0 [head mm/s]
G1 X7.31 Y32.01 E3.7689 F15000
G1 E6.3189 F1200
; trigger prime
G11
G1 X7.59 Y28.97 E6.3667
