Issues with GCODE Preview

Johan

Hello

I have a Cerberus delta printer. Ive been using Repetier Host on my CAD system (which is great btw). Ive really been wanting to offload the actual printing to another system, somehow. I heard about the new Raspberry Pi 2, so I ordered one, along with the Pi camera.

I also heard about Octoprint, so I installed that on the Pi. Wow. Woefully inadequate!

So I went in search of another package for the Pi, and came across Repetier Server (I didnt know about it, only the Host). So I installed that. MUCH more promising/robust!
I even found/followed the instructions (on this site) for how to set up the camera, and that works great, although it took some Googling/Youtubing in order to find those instructions.

I do have some issues with the Server software though, now that I have it installed and working:

Gcode Preview Errors

- I defined the Z-Max and Z-Home Position in printer settings to be 320mm.
- I uploaded a simple, small gcode file of an 80mm diameter washer (sliced in Kiss, its only 460kB).
- I clicked the icon to preview it.
- In the Preview Window, it says the Z Position of layer 1 is 320mm (incorrect). In the actual model preview window, it only shows me a black dot in the lower left corner, and one green line going up and to the right at a 45 degree angle (which appears to be a move), and nothing else.
- If I click "+" next to Layer, it shows me Z position of 0.2mm for layer 2 (which is about right). Also, I now see the first layer gcode, EXCEPT I only see the upper right corner of the model/print (like your software cut a 1/4 pie slice out of the gcode)?! The other 3/4s of it is simply not there. Also, if I move the percentage dial, it thinks the model starts at the black dot (which is incorrect).
Is there something in the software which is somehow limiting the amount of the gcode being displayed?
If so, Ive
looked at every setting in the interface, and I dont see anything which will change this.

- I uploaded another simple model, a rectangular calibration box. When I preview it, it does show me the entire box, although the surrounding skirt has been truncated to be the same/similar 1/4 (upper right). So its not the model of my washer that is causing an issue.

- In addition, the extrusion paths on the square box are not being shown correctly. Where parallel lines exist in the gcode (to fill the bottom layer of the box), in the preview, over 50% of the lines converge, as if they are starting at a single point in the layer. Thats certainly not how this model prints in reality.

- If I print this model, and click over to the Control window, it shows me the extrusion paths the same way, ie as if they are all converging to a single point. This does not match what is going on, on the printer.

Wierdness in the GUI

- If I dont select a file to print, and then click on the Control tab, it just shows me an empty bed. Why not combine the preview screen and the control screen into one?

- If I click over to the Print tab, and then back to the Control tab, the view is completely "zoomed out" (ie its fitting the image of the entire bed to the preview window). I have to zoom all the way in again to see the model. Why doesnt it stay at the zoom level I had before?

Lack of Controls/Placement of Controls

- On the Control Tab, there arent any buttons to STOP, or PAUSE the print?! It requires me clicking back to the Print Tab in order to stop the print.

- The Hot End and Bed Temp controls are way down at the bottom of the screen.
Im my opinion, ALL the controls need to be in one place (close to the Speed, Flow, and Fan Controls. I cant imagine controlling this printer from a tablet or my smart phone (without a scroll wheel).

- The little line graphs are kind of cool, although if you have a
simple way to show the target/actual temps of everything, up near the controls, that will be far more
effective. Also less scrolling. Note: there's no scrolling in Repetier host on the Manual Controls screen.

Come to think of it, why re-invent the wheel? I suggest you model this user interface to look as much like Repetier Host as possible. MUCH less transition time for users. Its taken me the better part of the day to "learn" this user interface.

ie After I choose a model, Im immediately taken to the Manual Controls Screen, where I can see the display of the gcode (the graphical display, in real time), and have all the controls right there at my fingertips, including buttons to START/STOP/CANCEL the print.

Easy peasy.

- There needs to be a way to define the commands sent to the printer if I hit STOP/CANCEL.

Thanks for all your work thus far, its a good beginning.

Repetier

Thanks for your thoughts.

First some things already included:

1. 1/4 problem is easy to solve. In printer configuration you have the shape but on the first tab you have the possible move volume where you limited x,y to 0. That causes the 1/4 effect. Unfortunately changing them does currently not correct old previews. Add buffer to 17 and save to force rerendering previews.

2. You can define gcode for stop/pause etc. in printer configuration -> gcodes -> Event depending you can set them.

Some good new - next host release will have a server connector so you can use the host also it talks directly with server running on your pi. Hope you will like that :-)

Would be great to get you kisslicer gcode to see why layer 0 starts at top in your case. Idea is to start at 0 but I guess something confuses the interpreter.

"- If I dont select a file to print, and then click on the Control tab, it just shows me an empty bed. Why not combine the preview screen and the control screen into one?"

what should I show there if you are not printing. It will show all moves and extruder position. Preview screen is not designed to allow controlling like in control tab.

Switching tab problem. Each tab is a own view with controller. So leaving it means loosing position data. I agree that holding last view position would be great and hopefully find a solution to store it somewhere upwards where it does not get deleted directly.

Controls tab: That is hard to design. In contrast to the host we wanted it also to be usable on smartphones and tabs. That needs some more space and also the ability to move controls around to fit to different width while host is quite static here allowing a more compact design. Especially the temperature controls are not as perfect as I might want them and I will think about your ideas and how we could combine it.

Johan

Thanks for the fast reply.

re: 1/4 view issue. Ok you lost me. You said "In printer configuration you have the shape but on the first tab you have the possible move volume where you limited x,y to 0."

My printer is 400mm Diameter (so 200mm Radius), and its build volume is 320mm high.

On Printer Settings I have:
X-Min 0
Y-Min 0
X-Max 200
Y-Max 200
Z-max 320
X-Home 0
Y-Home 0
Z-Home 320

Are these not the correct settings?

----------------------------------

RE: Server Connector. If I understand you correctly, Repetier Host, running on my windows 7 CAD System, will be able to communicate with the Server? Thats a very interesting concept.

Here's what Ive been pondering as far as workflow...

I have an HP Laser printer. Im running an app, say MS Word, on my desktop system. I have a document prepared, on the screen. I hit print preview. In a pop up window, Im able to see what the print is going to look like on the actual printed page.

If I like it, I hit Print. It sends the file over to my printer (via a network connection/port on the printer, not USB, so VERY fast). The printer "wakes up", calibrates, warms up, and then a few minutes later my document spits out the top of the printer.

Im envisioning something identical with my 3D printer. Im in a CAD program. I hit Print Preview. In a popup window, it shows me my 3D model. Alongside it are adjustable parameters, which I can adjust.

When I like what I see, I hit a Print button. It sends a file (NOT gcode, say something like an .obj file), along with the parameters Ive defined in the print preview, over to the Pi, via my LAN (in my case my Pi is hardwired to a switch, so a very fast connection).

On the Pi the model is sliced, and sends the gcode to the printer. (Note: I dont see why the file cant be sliced in real time, not ahead of time, just like ray tracing an image, one raster line at a time, but thats a whole 'nother topic of discussion. If we can somehow have slicing on the Pi, it will definitely be a step in the right direction, even if its all done pre-processed, ie before the actual printing begins).

After the file is sent to the Pi, Im able to do one of two things.

I) log into the Pi from my desktop, such as through the browser, like you have the beginnings of now.
Im able see
- the camera video stream,
- the gcode "stream" (just like the host program does now) and
- control the print including (but not necessarily limited to) the
a) Speed
b) Flow
c) bed temp
d) hotend temp
e) chamber temp (my printer has a heated build chamber)
f) Stop/Abort the print.

Preferably all the above on compact screen. I understand you are wanting to allow for small screens, such as a smart phone, tablet etc. Its like the mobile versions of web sites versus a desktop version. Once again thats an entirely different discussion.

II) Alternatively I want to add a touch screen to the Pi (eliminate the LCD screen it has now, which is crude and useless as far as Im concerned), and be able to go stand in front of the printer, and have the same real time controls available to me.

BTW Ive been a computer programmer for over 30 years, and a web developer for over 15 years. If there's any way I can help speed up the development of the above, such as being a Beta tester, or even writing some of the code, Im interested to talk to you about it.

Here's a question for you. Is a user able to customize the layout of the HTML screens in the Server package right now??
My mail server gives me that flexibility. The pages of the web interface are entirely customizable. They must be separated somehow from the actual core code. Maybe a model like that applies here? I dont know. Im just kicking out ideas here.

Best regards,
Johan

Repetier

With a radius 200mm around 0,0 you x-min and y-min should be -200 not 0. The rest makes sense.

To your vision. We are working somehow towards it, not sure how far we will get.

Slicer sill go inside Pi. Especially the Pi2 with 1gb should be able to slice medium complex stl files. For more complex cases we want to add remote slicing. We also want a fast mode just uploading a stl for printing - set some slicing parameter and convert directly to gcode. Also slicing starts at the top to project supports so it can not start directly - but that is only a question of time not of user interactions.

We are currently designing interfaces suiteable for front panels. These come as templates, so everyone can change them on it's own.

In theory you can also modify the web frontend, but we have packed javascript and html for fast lading times etc, so it is not easy editable and every update will destroy the work. What we started implementing is a modules system to extend it. So once it is finished, it should be easy to add function, new tab pages, menu entries, ... and they will survive updates.

I also think I'd like to leave the manual-control more or less like it is and add some extras to the print tab when printing, so that you can see the most important values there as well es change them in a compact way. The controls are more in case you are not printing but want to finetune your printer.

Johan

Thanks again for another fast reply.

re: 1/4 view issue. It suddenly occurred to me (while sleeping, lol) what the issue was. I came back here to the forum to tell you I had figured it out, then I saw your reply. Yes, changing the XMin and YMin settings took care of that mystery.
This is yet another issue which can cause a lot of confusion with 3DP newbies, like me. ie The Z axis min is totally different from the X/Y Axis min(s). I suppose there's no way around that with a Delta Printer.

re: My 'Vision' for the workflow.
I think many others will likely concur with me on the overall workflow with 3D printers. It needs to be simple, and more importantly, similar to the existing workflow with laser printers, which has been established and used for decades.

re: user modification of the front end
I understand what you are saying, in that updates from the author (your team) can 'clobber' user mods, and yet, if the system is setup correctly, those types of issues can be overcome. Evidently you've already started working on something along those lines.

So I can get back to work, on my parts, which is why I bought this 3D printer in the 1st place, and for the near future, here's what Im requesting:

- Nix the separate preview screen (I still dont see the login in having that as a separate screen)

- The left side of the screen has a LOT of wasted space/real estate right now (where I choose the printer). Move that to the top, or somewhere else, to choose the printer. Dont most people, like me, have only one printer?

- Make the control/printing screen VERY similar (as identical as possible) to the Manual Control Screen in the Host Program.

- Have a row of buttons across the top, to allow loading of the model, and starting the actual print.

- The next row, below them (from left to right):

Col #1: The vertical column of icons, to allow fast/easy control of the viewing of the model ie zoom etc (right now you have those on the preview window, and yet, NOT on the control window?)

Col #2: The model/gcode preview window

Col #3:
- The controls of the printer on the right side, ie the 5 that you have now in the host program, concisely showing the target/current temps and speeds.
Note: I HIGHLY recommend nixing the line graphs. Not only do they take up a lot of space; it requires scrolling down to the see 2 of the most important parameters, the hotend and bed temps!
Plus, Im only interested in the current temps, ie target and actual. I dont really see the usefulness of the temps 5 minutes ago?

- One additional control, which allows monitoring/control of the chamber temp, for those (like me) that have an HBC.
My printer uses an M440 command to set the chamber temp (I dont know if that is a standard gcode command for chamber temp or not).
The feedback lines from my printer look like this:
16:45:00: ok T:26.9 /20.0 @0 B:30.5 /20.0 @0 C:29.0 /80.0 @255
BTW this is something Im also requesting for the host program :-)

- IMPORTANT - The webcam video stream (this is of course an
additional little window, which is obviously not needed in the Host
program)

PS Why doesnt your forum email me when subsequent posts are added to this thread, which I started? That seems strange to me, that it requires me to re-visit this page, in order to see your responses?

Best regards
Johan

Repetier

I have discussed your ideas with my partner and we came up with some great improvements. Will try to implement them and see if they are as great as we think:-) Includes many of your ideas so I guess you will like them as well. Gives overall more information on less space.

Johan

Thank you for taking my observations in the spirit in which they were intended, which were to improve your products. As I mentioned previously, Ive been a programmer for many years. And I have always focused on the MMI (the man-machine interface). The simpler, and the more intuitive, the better.

 

If a new user can pick up your product, and be able to use it, without having to read a manual (RTFM), and it works well, for what it was designed to do, then you will have a dynamite product. Also a product worthy of an admission fee.

Update: Ive been testing RS with a simple model, with 'cold' temps, and no filament in the printer, so I can see how it behaves and to get to know the user interface. 

Last night I wanted to go to the next level in my testing. So I put filament into the printer, and uploaded a 'real' model. And unless Im missing something here, there is a distinct absence of controls in order to extrude some filament through the hot end. Thats a basic function which appears to be missing. Please add that to the list.

I also suggest a separate screen where a user can setup the printer, do things like level the bed, etc and get it ready to do a print. This screen will have the basic motor controls ie X, Y, Z movements, and I also highly recommend putting some presets in there so the user can level the bed.

Note: I customized the menus on my delta printer, to position the hotend to 4 different positions. It is my intent to eliminate the LCD screen entirely, and instead have a touch screen attached to the Pi.  If RS has all these basic functions in it, then I can remove the LCD. Hence my earlier request in this thread for some sort of app, which runs natively on the Pi, and facilitates the touch screen. I dont know if that is possible without loading X (and the GUI for the OS) or if that can be bypassed entirely, as that will likely add a LOT of overhead to the system. I welcome yoour thoughts about this aspect of this system.

One more ?.. How does one update RS on the Pi? Does that require downloading another .deb file, and manually installing it on the Pi (such as through SSH), or once RS is installed, does an ap-get update and apt-get upgrade do the trick? While Ive been a programmer for many years, Ive only started to learn about the idosyncrasies of linux about 2 years ago.

Have a good one.

BR,

Johan

Repetier

Have already started implementing the ideas and looks good so far.

For extruding use Extrude and retract function in the extruder menu. Next version will have quick temperature view at the top and clickit at it will show a popup where you can control it.

LCD support is coming as a demo implementation of a web app. So it can be run from a browser in x windows in full screen mode. That app is reduced to function like you expect on the lcd and more lightweight then the normal fronend app. It is implemented as module so you can copy it and modify it to your wishes. Mainly meant for vendors to customize it to their own wishes/design but off course everyone can do it.

Updating is just like installing. It will overwrite the executeable files. Config data and models are stored in a different directory and not affected by this.

Johan

Wow! I really appreciate your taking these ideas and running with them. Thats great!

I will look at the extruder menu. Thanks. Ive been testing RS alongside Octoprint and moving fairly quickly through my testing, so I very likely missed that.

So if I understand you correctly, you're suggesting simply running x windows on the Pi, a browser in full screen mode, and just connecting to the web server (RS) on it? I thought about doing that. While that will certainly work, I still wonder how much RAM (of the 1 gig in the Pi 2) and CPU will be consumed by all that? 

Have you done any testing of this, and do you have any statistics on the resources (ie Ram/processor) which all that consumes? Im talking during a print.. ;-)

Especially if we are talking in terms of doing actual slicing on the Pi.  I still have that on my desires list, albeit its nowhere near the top at this point. If we can get some basic things in place I will be very pleased.

In the meantime, Im in search of a touch screen for the Pi. Im thinking something around a 7 inch size?  Ideally, if someone out there has already made the stl files available so I can quickly print a case, that will be a bonus.. something which will house the Pi, the touch screen on the front, and the Pi camera on the back. Adafruit has the above, altho its for a little 2.8" touch. Im thinking thats too small.

My printer has clear lexan doors all the way around. The lcd screen that came with it is mounted about half way up on the front door. If/when what we have been discussing all comes together, I can simply remove the LCD screen, and mount this assembly in its place. That way the Pi camera can be positioned in the right spot. Note: The Pi camera has a very short ribbon cable. 

Who knows? I might be thinking too far out of the box? I already have a nice Samsung tablet, which I can always simply carry with me when I go out to my computer room, which is where I want to put this 3D printer, as soon as possible, and get it out of the house. Even though it is not as noisy as a cartesian printer, it can still be heard throughout my house when its running.

In addition, I print pretty much exclusively in ABS, and even though the printer is enclosed, the smell does still permeate the house

Carry on gents! Looking forward to seeing what you come up with.

By the way, what is your name? I like to address people by their name when Im communicating with them. Its a respect thing.

BR, Johan

Repetier

Yes I plan using a browser. But not with the normal frontend, that is too resource hungry. I want a smaller app for the pi lcd, which is what we are working on. In fact users tried the normal frontend and server crashed, also it was a pi 1. SInce interface is not finished I haven't tested it so far. Still developing and hoping it will work:-) 

First resolution is 1024x800 pixel as that is what I have a display for. If that works we will continue adapting it to smaller resolutions which is hopefully faster.

Slicer will come at some point. Just after frontend and gcode preview i guess. Here we plan also remote slicing in case memory is not large enough.

Roland

Johan

Roland

As engineers/programmers, we are constantly balancing the requests/desires of the users/workflow against our box of tools 

a) the hardware and low level software tools available to us at any given time, 

b) our knowledge level of those tools, 

c) and the real critical factor, which is time. There are only so many hours in the day, especialy when, as in my case, Im doing most of my own product development, by myself.

I totally see your point about the amount of resources used in order to provide 'local' control of the printer (ie a screen directly attached to the Pi) at the same time as acting as a web server to provide 'remote' control. Ive had many of the same thoughts/concerns.

On top of controlling the printer, and feeding layers of gcode to it during a print, the ideal workflow throws other things into the mix, such as streaming the video from the attached camera, and other desires, such as slicing on the Pi itself. 

Note: Since the Pi camera is not connected thru USB (the Pi camera is what Im using/testing), I wonder if the drain on the USB bus might be less? hmmm

In addition, I have the Pi2 connected to the network 'hardwired', not through WiFi. I wonder if that helps as far as resources too, ie the web server portion of the code is not streaming output thru USB either? Im mostly a software engineer, not a hardware engineer, so these things are somewhat out of my realm of expertise.

As Ive mentioned, to me the workflow is the most important thing. Sometimes us developers need to just step back far enough from the forest, in order to better see the trees. ;-)

I had some more thoughts last night, which I will throw out onto the table..

It seems to me there are functions which are more appropriate to be present locallly, versus remotely.

Are we ever going to be doing things like leveling the bed, extruding plastic after putting in a different roll of filament, etc 'remotely'? 

No. Those are 'local' functions, which we do when we are standing in front of the printer.

Are we going to be watchiing the camera feed when we are standing in front of the printer? 

No. That is a function which we only want to do remotely.

So there's definitely a dividing line forming in my mind about these two disparate areas.

Here's a thought I had last night.. 

Is it possible to detect when then browser is being run on the Pi itself? 

If so, then only certain functions can be displayed on the screen in that case. ie functions which allow us to do maintenance/prep on the printer. 

If we are not on the display of the Pi itself, then other functions can be loaded/displayed.

Once again, there's only so many hours in the day. So maybe presenting the local functions is best done through the same presentation method (ie the browser) for now, and then later carve those functions out and make them into a native app?

Btw if you want me to do some beta testing for you, in a pre-release to the public scenario, Im avail for that type of activity.

Another btw. Im working closely with the manufacturer of my cerberus printer to help them improve/market/sell this printer. Im providing them feedback on what Im doing with the printer, to make it better. Even though this is already an AWESOME machine, there's of course, always room for improvement. 

I can envision a bundled system, with their printers, and a 'branded' version of your software. Might make for a powerful combo.

Johan

crocky

Hi Johan,

Did you use the instructions for making mjpg-streamer as written here.. Mine gives me an error during the make!

Can't remember the error message at present. I will try it again and see if it works. I am using a raspberry Pi 2, 32Gb, Pi camera.

I like some of your changes too. I only got mine working yesterday and a 9 hour print job was no problem. My slicing is done on a Mac with registered Kisslicer.

Bob

crocky

Got the make to work, small typo on my part

Still not producing video yet.... I have a few things to check now.. 1 step at a time...

Repetier

@johan As you might have seen version 0.60 is out which now has 2 web interfaces. One for local attached display for direct control. This is also a bit easier so pi 2 has no problems rendering it and it is easier as it is reduced to direct printer actions you typical want to do. And that interface is just a template so printer vendors can adapt it to their special needs and wishes. All they need to do is copy the module as described in online docs and make their changes. Only thing I found some small problems which will be solved in 0.60.1