Software Report Format

Discussions about ideaMaker and other printing software.
User avatar
Vicky@Raise3D
Posts: 3325
Joined: Fri Mar 25, 2016 3:54 am

Software Report Format

Postby Vicky@Raise3D » Fri Dec 15, 2017 8:04 am

Dear all,

To improve the efficiency of collecting software problem, we have designed a format for everyone to submit the report, including bug, feature request and doubt about the current existing functions. We will invite the software team to join and check together all the reports with this format every weekday.
1.png

Please define the subject of your report as the following format so that the software team can distinguish your report from other hardware or printing setting posts directly:
[BUG][IM-3.0.2]breif title
[FEATURE][IM-3.0.4]breif title
[OPERATION][IM-3.0.1]breif title



The format of content, please follow below information.

1. Bug Report:
Title: [The name of the bug]
Description: [Brief description of the bug]
Version: [Version number of your ideaMaker]
Language: [Under which language you meet with the bug]
Operation System: [Which operation system installed on your computer]
GPU: [Model type of your graphics card]
32bit or 64bit:
Screen Resolution:
How to trigger the bug: [List the steps one by one which can reproduce the bug.]
Expected Result: [What is your exception result with the above steps]
Real Result: [What does ideaMaker finally do with the above steps]
Attachment: [All the attachments need to be compressed to be a single file.]
    .gcode file
    .data file
    Pictures
Note: The above three are necessary files to be attached to report a bug. If you have other files can show the bug, please attach together with these. The community only accept Zip type file. If the files are too large, please shoot a mail to bug_report@raise3d.com

2. Feature Request:
Title: [The name of the feature]
Description: [Brief description of the feature]
Version: [Version number of your ideaMaker]
Operation System: [Which operation system installed on your computer]
Reason: [To explain why this feature is needed]

3. How to Use
Title: [The name of the operation]
Description: [Brief description of your doubt]
Version: [Version number of your ideaMaker]
Language: [Under which language you meet with the bug]
Operation System: [Which operation system installed on your computer]
GPU: [Model type of your graphics card]
32bit or 64bit:
Screen Resolution:
Expected Result: [What is your exception result with the function]

DeX
Posts: 75
Joined: Fri Apr 21, 2017 6:56 am

Re: Software Report Format

Postby DeX » Fri Dec 15, 2017 1:33 pm

Чото очень сложна! Хочешь вам помочь, а вы усложняете. :( Сделайте багрепорт из программы IM что-ли, пусть она собирает всякую инфу не касающуюся багов.

User avatar
Michael.P@Raise3D
Posts: 225
Joined: Wed Jul 20, 2016 4:51 pm
Location: Costa Mesa
Contact:

Re: Software Report Format

Postby Michael.P@Raise3D » Fri Dec 15, 2017 5:51 pm

@DeX,

This may seem complicated on your end but it is much simpler on ours to track at the moment. Please bear with us on this until we have a more streamline way of collecting the information.
Michael Petitclerc, Technician
Tel: +888 963 9028
Web: http://www.raise3d.com

Tinkerer
Posts: 176
Joined: Mon Oct 09, 2017 8:30 pm
Location: Germany

Re: Software Report Format

Postby Tinkerer » Fri Dec 22, 2017 1:34 pm

Dear Raise3D team!

I totally understand and support your efforts in establishing a professional bug/feature request handling.
Absolutely makes sense.

As I have been working in SW-Development as well as in Support-Management in the past myself,
I really understand the situation you are in.

Customers expect you to go after the issues they encounter, to get feedback what happened, what will happen.
They throw more or less qualified "bug reports" to you.
Developers start to loose oversight which problem to tackle first, which problems might interfere with others etc. pp.
They may miss details they would like to know to be able to understand the problem and solve it.

From my very own experience with such situations I would like to give you my point of view:

NEVER EVER use a statement like this:
"This may seem complicated on your end but it is much simpler on ours..."

Yes, I know ideamaker is available as a free software as well.
But for the people that bought an N-series printer from Raise3D it is an essential part of the system.
Only with ideamaker one can use all the advertised comfort-features of the machine (e.g. remote monitoring etc.).

And it came with the printer, so it's part of the product bought by customers.
So I'd like to say these (paying) customers have a solid reason to expect the manufacturer (Raise3D) to care.

It's fine to involve customers in beta testing and improving things - a little bit, that's okay.
It's questionable what one defines as "a little bit" but that's something completely different...

It may also be the new normal that products today come with a lot of "areas for improvement" -
which used to be a no go in "the old times", but again, that's something completely different...

But when you expect people to participate in the product development life cycle - you need to motivate them to do so.
Telling a customer "I'd like you to put in more efforts so I do have less" is not motivating.
I'd even like to say it's sort of cheeky.

I have done something very similar when I was responsible for handling critical customer situations at a big
global IT-company.
I published a form to be filled in before we took action.
A well thought out form, covering all and every possibly areas of importance for us.
And guess what?
It was a great failure.

People hesitated to fill in all and everything everytime.
Access to the form was to complicated.
The colleagues told me it was too intransparent whether their efforts put in this form would give them a return.
And more.

What we did back then, we streamlined the process.
Asking very few things in the first run, assessing the issue on our side, managing the needed details in our own record keeping system.
And then beeing able to get back to the requester with questions if needed. Plus giving qualified feedback.

I learned that people are willing to participate in solving a problem - but only to a certain point.

So what would I do if I were in your situation?
1. Consider a devops-style of operation
2. strengthen test-plan/-management integration with development
3. increase documentation requirements ("No, that module is not yet ready. There no documentation, dear developer/tester/...")
4. setup a feedback-system thats easy to handle (ideally on both sides;-) &
5. interface that with an internal record management system
Finally I'd try to listen to my customers and motivate them to co-operate;-)

Just my thoughts/experience.
...there's nothing like the smell of fresh ABS in the morning...

User avatar
Vicky@Raise3D
Posts: 3325
Joined: Fri Mar 25, 2016 3:54 am

Re: Software Report Format

Postby Vicky@Raise3D » Sat Dec 23, 2017 2:32 pm

Tinkerer wrote:Dear Raise3D team!

I totally understand and support your efforts in establishing a professional bug/feature request handling.
Absolutely makes sense.

As I have been working in SW-Development as well as in Support-Management in the past myself,
I really understand the situation you are in.

Customers expect you to go after the issues they encounter, to get feedback what happened, what will happen.
They throw more or less qualified "bug reports" to you.
Developers start to loose oversight which problem to tackle first, which problems might interfere with others etc. pp.
They may miss details they would like to know to be able to understand the problem and solve it.

From my very own experience with such situations I would like to give you my point of view:

NEVER EVER use a statement like this:
"This may seem complicated on your end but it is much simpler on ours..."

Yes, I know ideamaker is available as a free software as well.
But for the people that bought an N-series printer from Raise3D it is an essential part of the system.
Only with ideamaker one can use all the advertised comfort-features of the machine (e.g. remote monitoring etc.).

And it came with the printer, so it's part of the product bought by customers.
So I'd like to say these (paying) customers have a solid reason to expect the manufacturer (Raise3D) to care.

It's fine to involve customers in beta testing and improving things - a little bit, that's okay.
It's questionable what one defines as "a little bit" but that's something completely different...

It may also be the new normal that products today come with a lot of "areas for improvement" -
which used to be a no go in "the old times", but again, that's something completely different...

But when you expect people to participate in the product development life cycle - you need to motivate them to do so.
Telling a customer "I'd like you to put in more efforts so I do have less" is not motivating.
I'd even like to say it's sort of cheeky.

I have done something very similar when I was responsible for handling critical customer situations at a big
global IT-company.
I published a form to be filled in before we took action.
A well thought out form, covering all and every possibly areas of importance for us.
And guess what?
It was a great failure.

People hesitated to fill in all and everything everytime.
Access to the form was to complicated.
The colleagues told me it was too intransparent whether their efforts put in this form would give them a return.
And more.

What we did back then, we streamlined the process.
Asking very few things in the first run, assessing the issue on our side, managing the needed details in our own record keeping system.
And then beeing able to get back to the requester with questions if needed. Plus giving qualified feedback.

I learned that people are willing to participate in solving a problem - but only to a certain point.

So what would I do if I were in your situation?
1. Consider a devops-style of operation
2. strengthen test-plan/-management integration with development
3. increase documentation requirements ("No, that module is not yet ready. There no documentation, dear developer/tester/...")
4. setup a feedback-system thats easy to handle (ideally on both sides;-) &
5. interface that with an internal record management system
Finally I'd try to listen to my customers and motivate them to co-operate;-)

Just my thoughts/experience.


Thanks so much for all your inputs!
Really give us some different thoughts besides the current working way of ours.
Will discuss with R&D team about this.

heromero090
Posts: 2
Joined: Sat Jan 13, 2018 6:53 pm

[BUG][IM-3.0.2]breif title

Postby heromero090 » Sat Jan 13, 2018 7:15 pm

Title: Software don not take in account the "RAFT GAP FROM MODEL"
Description: I set up the RAFT GAP FROM MODEL on: 0.5mm.. then slicer, then print. the printer finish the Raft and the FIRST layer good. the problem is on the Second layer. the second layer do not have the 0.5mm plus..

more specific, the Last Raft layer (LAYER -1) is on Height Z=1.320,,
the fisrt Layer (LAYER 0) is on Height Z=2.120
Here all is OK,, (the fisr Layer set up is Height=0.3mm and the Layer Height = 0.25)

So 1.320 (Last Raft Layer) + 0.3 (First Layer Height) + 0.5 (Raft Gap from model) = 2.120.. All is ok

But when the Second Layer (LAYER 1) is Height Z=1.870

So 1.320 (Last Raft Layer) + 0.3 (First Layer Height) + 0.25 (Normal Layer Height)) = 1.870

the Second Layer is under the First Layer. Why? because the Second layer do not take in account the RAFT GAP FROM MODEL.

Version: 3.0.5.1438
Language: English
Operation System: Windows 7 Enterprise
GPU: AMD Radeon R5
32bit or 64bit: 64 Bits
Screen Resolution: 3840 * 1080
How to trigger the bug: Gcode inspection
Expected Result: the Second and all the Layers need to have the RAFT GAP FROM MODEL.

User avatar
Vicky@Raise3D
Posts: 3325
Joined: Fri Mar 25, 2016 3:54 am

Re: [BUG][IM-3.0.2]breif title

Postby Vicky@Raise3D » Mon Jan 15, 2018 6:58 am

heromero090 wrote:Title: Software don not take in account the "RAFT GAP FROM MODEL"
Description: I set up the RAFT GAP FROM MODEL on: 0.5mm.. then slicer, then print. the printer finish the Raft and the FIRST layer good. the problem is on the Second layer. the second layer do not have the 0.5mm plus..

more specific, the Last Raft layer (LAYER -1) is on Height Z=1.320,,
the fisrt Layer (LAYER 0) is on Height Z=2.120
Here all is OK,, (the fisr Layer set up is Height=0.3mm and the Layer Height = 0.25)

So 1.320 (Last Raft Layer) + 0.3 (First Layer Height) + 0.5 (Raft Gap from model) = 2.120.. All is ok

But when the Second Layer (LAYER 1) is Height Z=1.870

So 1.320 (Last Raft Layer) + 0.3 (First Layer Height) + 0.25 (Normal Layer Height)) = 1.870

the Second Layer is under the First Layer. Why? because the Second layer do not take in account the RAFT GAP FROM MODEL.

Version: 3.0.5.1438
Language: English
Operation System: Windows 7 Enterprise
GPU: AMD Radeon R5
32bit or 64bit: 64 Bits
Screen Resolution: 3840 * 1080
How to trigger the bug: Gcode inspection
Expected Result: the Second and all the Layers need to have the RAFT GAP FROM MODEL.


If take the gap into calculation for all the following layers, the following layers will hard to bond with each other tightly. The whole structure will be very loose.
Imagine, with 0.5mm gap from Raft to print a 0.3mm thick layer, the nozzle start extruder at 0.8mm height from Raft. The 0.3mm thick line will drop from 0.8mm height to the surface of the Raft. If continue moving nozzle up, for example another 0.25mm more, from 0.8mm to 1.05mm height, but the real height of the first layer is only 0.3mm or a little more higher than 0.3mm. With such large gap between nozzle and first layer, it is hard to stick the second layer with the first properly. And the extrusion width of the following lines will be uneven as well.

Here have some discussions about this matter before: viewtopic.php?f=8&t=4758&p=21881&hilit=raft+gap#p21695

heromero090
Posts: 2
Joined: Sat Jan 13, 2018 6:53 pm

Re: [BUG][IM-3.0.2]breif title

Postby heromero090 » Mon Jan 15, 2018 3:02 pm

Vicky@Raise3D wrote:
heromero090 wrote:Title: Software don not take in account the "RAFT GAP FROM MODEL"
Description: I set up the RAFT GAP FROM MODEL on: 0.5mm.. then slicer, then print. the printer finish the Raft and the FIRST layer good. the problem is on the Second layer. the second layer do not have the 0.5mm plus..

more specific, the Last Raft layer (LAYER -1) is on Height Z=1.320,,
the fisrt Layer (LAYER 0) is on Height Z=2.120
Here all is OK,, (the fisr Layer set up is Height=0.3mm and the Layer Height = 0.25)

So 1.320 (Last Raft Layer) + 0.3 (First Layer Height) + 0.5 (Raft Gap from model) = 2.120.. All is ok

But when the Second Layer (LAYER 1) is Height Z=1.870

So 1.320 (Last Raft Layer) + 0.3 (First Layer Height) + 0.25 (Normal Layer Height)) = 1.870

the Second Layer is under the First Layer. Why? because the Second layer do not take in account the RAFT GAP FROM MODEL.

Version: 3.0.5.1438
Language: English
Operation System: Windows 7 Enterprise
GPU: AMD Radeon R5
32bit or 64bit: 64 Bits
Screen Resolution: 3840 * 1080
How to trigger the bug: Gcode inspection
Expected Result: the Second and all the Layers need to have the RAFT GAP FROM MODEL.


If take the gap into calculation for all the following layers, the following layers will hard to bond with each other tightly. The whole structure will be very loose.
Imagine, with 0.5mm gap from Raft to print a 0.3mm thick layer, the nozzle starts extruding at 0.8mm height from Raft. The 0.3mm thick line will drop from 0.8mm height to the surface of the Raft. If continue moving nozzle up, for example another 0.25mm more, from 0.8mm to 1.05mm height, but the real height of the first layer is only 0.3mm or a little more higher than 0.3mm (because the dropped down line is not such tightly bond to Raft). With such large gap between nozzle and first layer, it is hard to stick the second layer with the first properly. And the extrusion width of the following lines will be uneven as well.

Here have some discussions about this matter before: viewtopic.php?f=8&t=4758&p=21881&hilit=raft+gap#p21695



OHHHH LOL . you're right ...
My bad, sorry.. jaja

Thanks vicky

fischer99
Posts: 5
Joined: Sat Dec 16, 2017 5:33 am

Feature Request IM 3.1.0.1545

Postby fischer99 » Fri Feb 09, 2018 4:16 pm

Feature Request:
Title: z-hop while traveling with options
Description: Please provide z-hop while the print head is traveling. This could be used in conjunction with "retract at layer change". There should be options to apply z-hop while traveling "All the time", "Infill only", "only z-hop for outer surfaces" (top and bottom layers).
Version: 3.1.0.1545
Operation System: Win10
Reason: I do a lot of emblems and key chains. This really applies to anything with a flat surface which is meant to be cosmetically important, but travel lines moving across the print (not part of a retraction move) can leave scars in the top/bottom most surfaces. The top and/or bottom surfaces are cosmetically important so leaving travel lines across the primary surfaces can ruin the print. a z-hop while traveling or an option to "avoid printed surfaces while traveling" would be a great feature. Understanding that this could potentially increase print time, it does greatly reduce the clean-up, post processing, and potentially trashing of prints.

Thanks for the consideration.

Marc F

jon_bondy
Posts: 91
Joined: Fri Jan 26, 2018 6:24 pm

Slicing bugs

Postby jon_bondy » Mon Feb 26, 2018 6:40 pm

Parts of this STL are so thin that the slicer fails. Horizontal gaps appear on each side of the nostrils. I don't mind the slicer failing, but there should be error messages to warn the user that something has gone wrong

http://www.jonbondy.com/sample.stl

When this STL is sliced, pieces of filament jut out of the object in the Preview

http://www.jonbondy.com/sample2.stl

User avatar
Vicky@Raise3D
Posts: 3325
Joined: Fri Mar 25, 2016 3:54 am

Re: Slicing bugs

Postby Vicky@Raise3D » Tue Feb 27, 2018 7:10 am

jon_bondy wrote:Parts of this STL are so thin that the slicer fails. Horizontal gaps appear on each side of the nostrils. I don't mind the slicer failing, but there should be error messages to warn the user that something has gone wrong

http://www.jonbondy.com/sample.stl

When this STL is sliced, pieces of filament jut out of the object in the Preview

http://www.jonbondy.com/sample2.stl


It is due to those structures are too thin for software to check properly with Check Wall Check option under Other tab. Uncheck it, the preview will look better. But the most topping will hard to be printed out since it is too thin. And the layers approaching to top will be hard to print well, since they are too small size and have no chance to cool down and solid properly.

jon_bondy
Posts: 91
Joined: Fri Jan 26, 2018 6:24 pm

Feature request: remembering window sizes/positions

Postby jon_bondy » Tue Feb 27, 2018 11:59 am

Every time the main IdeaMaker window appears, it is the same size and in the same position; and it never is in the size and position that I chose previously. Same thing with the post-slicing Preview window. It would be nice of IdeaMaker remembered where the user last put these windows, and what size they were.

This is a nit, but when I slice and then do an Upload, I cannot close the Upload window until I have first closed the slicing window. This is strange, since I usually close windows in the reverse order in which I have created them. Is there a good reason for this behavior?

User avatar
Vicky@Raise3D
Posts: 3325
Joined: Fri Mar 25, 2016 3:54 am

Re: Feature request: remembering window sizes/positions

Postby Vicky@Raise3D » Wed Feb 28, 2018 3:55 am

jon_bondy wrote:Every time the main IdeaMaker window appears, it is the same size and in the same position; and it never is in the size and position that I chose previously. Same thing with the post-slicing Preview window. It would be nice of IdeaMaker remembered where the user last put these windows, and what size they were.

This is a nit, but when I slice and then do an Upload, I cannot close the Upload window until I have first closed the slicing window. This is strange, since I usually close windows in the reverse order in which I have created them. Is there a good reason for this behavior?


“Save and restore window state” and “Save and restore preview state” under Edit -> Preferences -> General.
1.png

jon_bondy
Posts: 91
Joined: Fri Jan 26, 2018 6:24 pm

Re: Software Report Format

Postby jon_bondy » Thu Mar 01, 2018 12:31 am

Thank you!

jon_bondy
Posts: 91
Joined: Fri Jan 26, 2018 6:24 pm

Feature Request: faster print termination

Postby jon_bondy » Thu Mar 01, 2018 3:36 pm

I started the wrong print, by accident. That print required that the build plate was at 100, which takes quite a while. I killed the print, but the printer insisted on getting up to 100 before it would quit. I finally just power-cycled the printer to save some time. It would be helpful if the printer could terminate a print quickly in all cases.

zemlin
Posts: 281
Joined: Sat Oct 21, 2017 2:02 pm

Re: Feature Request: faster print termination

Postby zemlin » Thu Mar 01, 2018 4:59 pm

jon_bondy wrote:I started the wrong print, by accident. That print required that the build plate was at 100, which takes quite a while.
I believe that's a limitation of Marlin - that it doesn't come looking for the next instruction until it's finished with that last one. Also it would be best to start a new thread rather than tacking your inquiry to the end of an unrelated thread.


Return to “Software”

Who is online

Users browsing this forum: No registered users and 2 guests