How to run ChiliPepr w/o internet (was Re: Software)

Discussion of tinyG control platform
Posts: 58
Joined: Sun Feb 01, 2015 1:12 am

Re: How to run ChiliPepr w/o internet (was Re: Software)

Post by sdumond » Sat Mar 28, 2015 8:27 pm

Personally, I think only accessing programs off the internet is ridiculous. I think in the long run a majority of us will find another avenue. I know I have to as I cannot access the internet from the shop and it is ridiculous to have to run to the internet and then back to the shop and pray it doesn't quit! I cannot get internet where I need it! There is still tons of us old fashioned people that don't have access to internet in their shop! I do believe they are losing or will lose a tremendous amount of their clients and disagree with that this is the way things are going. I think they don't even have a clue as to how many people don't have the cloud! The other programs like TGFX have poor memory management and operates at a snails pace about half way through. Chili peppr works great, but as I stated earlier is not going to work for me. Tired of running back and forth!!!! So I guess I will have to find a new controller, and I promise I will pass the word along about tinyg before people buy it and don't know any better! Had I have known this would be the biggest problem was finding a G code sender to my machine, I would have definitely went some other avenue!

I tried grblgru, but I cannot get it to connect to tinyg. All the other programs will, but not this one!

I am sorry for unloading, but this is the most frustrating thing to work out. I like the tinyg controller.Works well when it is hooked up to the machine. Paid pretty good money to get an upgraded controller, only to find no way to control it!

Posts: 115
Joined: Thu Jun 26, 2014 9:29 pm

Re: How to run ChiliPepr w/o internet (was Re: Software)

Post by jlauer » Wed Apr 01, 2015 5:20 pm

Hey guys, just read the thread for the first time. I think it makes sense for me to convey the vision for ChiliPeppr so folks understand why an offline version heavily complicates (even undermines) ChiliPeppr's goals.

Here were some core principles embraced in the design of ChiliPeppr:
  • ChiliPeppr must enable the community to modify and extend it as a core design philosophy, which means it must be easy and un-intimidating to edit.
  • ChiliPeppr is an open source project that will consist of people with day jobs, so it must allow for fast iteration cycles or it will not flourish and if it can't flourish it's not worth doing in the first place.
  • The browser is the new operating system that has surpassed any desktop development environment for developing apps so it must be embraced as a core design principle.
  • ChiliPeppr will make the developer documentation and developer community be included in the actual user-interface itself, i.e. why you have "fork widget" in the actual UI pulldown menus
Here were some old-style principles that were heavily rejected to try to create a new layer of thinking for the overall design:
  • Traditional desktop app
  • Packaged release cycles and installers
  • Inability to edit the codebase easily
  • Inability to find which part of the codebase represents which part of the UI
  • Operating system dependent codebase
  • Dependency management hell (maven, os-dependency, versioning, etc)
As a result of the core principles, I think it's worth exploring a list of things you would not have if ChiliPeppr supported offline as a main design goal:

1. You would not have workspaces.

This is a massive shift from traditional desktop apps and traditional web apps. I think folks arguing for offline are taking for granted how incredible workspaces are. They give the ability to the entire user community to create any flavor or mashup of widgets they'd like and then have those immediately available to everyone. This empowerment is why ChiliPeppr provides mass flexibility and future-proofing for the community. Getting rid of that via offline actually undermines this fundamental and I think folks asking for offline aren't actually considering this. To get into this mindset required tossing all preconceived notions of what an app is.

2. You would have no Grbl support.

The Grbl workspace was a result of the workspaces concept (which again is very unique on the web and I think other sites will copy). If workspaces weren't so easy to create, you would not have had a new member of the community (Jarret) just jump in on a weekend and fork a Grbl version which was immediately available to the online community. If offline had been the approach from day one there would be no Grbl support because nobody would have stepped in.

3. You would have no forking of widgets.

Any new developer is always loathed to go look at another developer's code. It's painful to try to get your head around how the original developer built stuff. That's why the majority of open source projects get no community involvement. Just look at all the dead projects on Github. For the UI to self-document which code file represents what UI widget is a breakthrough because it helps any new possible developer to immediately see the source code running in a development environment. It's basically like a billboard advertising for each widget saying "help me, i need improvements". The other key on this breakthrough, which can't be taken for granted, is the notion of the "IDE in the cloud" which is JSFiddle. If you had to setup your IDE exactly the way I set mine up, there would be almost no community involvement as folks would just give up really quickly. To achieve this magic combo, you need to be online, not offline. If offline had been a design approach, this whole concept would have been removed and ChiliPeppr would be a miserable piece of software today.

4. You would have no login capability.

Many current features are attached to the cloud login. The webcam server/client requires a login to share your peer-to-peer data connection. More and more new features will also be attached. JScut integration only exists due to the login. An upcoming release of SPJS will allow login from the command line so you no longer have to hunt for whip IP address SPJS is on. Future cloud storage of settings and retrieval of backed up iterations will be available. The ability to pull up a pendant view on your mobile phone will be enhanced due to the login so you don't have to hunt for IP addresses again for SPJS and so your Gcode file can be retrieved via webrtc peer-to-peer data connection.

5. You would have 10% of the feature set you have today.

- Too much wasted time on the packaging of releases.
- Too many features lost due to desktop software.
- Too much developer time wasted on dependency management.
- Too much time wasted on supporting folks who simply didn't upgrade to the latest release (this happens today on SPJS because it's a traditional desktop binary).
- Too much delay to new feature releases.

I am making this statement based on how easy it is to build apps in the browser today vs building traditional release-based apps that are packaged. I have over 20 years of experience doing software apps and I've learned the things that slow you down. Doing version releases and repackaging .zip files and .msi installers is one of those things. Trying to manage dependencies on a large Java project is one of those things. Trying to write one code base that runs on all operating systems is brutal. Those things have all been eliminated by embracing the "browser as the new operating system." The 3D viewer is the center piece of ChiliPeppr. That feature is enormously hard to write in any language, but the state of WebGL and frameworks like Three.js and the amount of community and examples around Three.js changed the game for making this core feature achievable. If ChiliPeppr had taken an approach of desktop or offline, this approach would not have been made, and thus you'd have less feature set because the 100 hours spent on the 3D viewer in Java would have gotten you 10% of what you have today in WebGL. This 10% can be extrapolated to almost every other aspect of ChiliPeppr because packaging everything for an offline release and creating an update cycle would mean of the hours spent on the project too high of a proportion would be wasted on stuff we've all learned can be eliminated from an online app.

6. You would not have as good of a UI because the browser would not have been used.

The ability to use CSS and the state of HTML and Jquery makes the browser a richer UI environment than anything out there today--way beyond JavaFX, way beyond .Net's XAML, and way way beyond QT's widgets or GTK. The webkit engine has billions of dollars invested in it today by Google, Apple, and other massive players. It is the pinnacle of the modern UI today and is the new operating system whether folks like it or not. People take for granted how hard it is to build good UI and for the time spent on ChiliPeppr, the UI is amazing because CSS/HTML and the browser DOM is just truly amazing today.

7. You would not get any of the future features that will change the game.

A major new feature being worked on right now is machine vision for ChiliPeppr. This means you can put two $10 USB microscopes on your Shapeoko and it can now do depth sensing to detect your Z zero from afar, detect the edge of your workpiece, auto-rotate your Gcode to match your workpiece, find fiducials (which include homing your machine via fiducials in your wasteboard rather than using limit switches). This requires OpenCV which is a C/C++ library. This means that to get anywhere with supporting this, it can't be desktop binaries because compiling for every platform out there like Windows 32bit/64bit, Mac OS X, Linux, Raspberry Pi, is a non-starter. Thus it must exist in the cloud. Google Compute Engine is the answer because it's almost free. The OpenCV machine vision engine will run in the cloud. You'll get full access to it. It will change the game for all Gcode sending apps into the future. It will only be possible because ChiliPeppr is an online app.

Here are other future features that require the cloud:

- A 3D library of CNC machines is in the works so that your machine can be viewed inside the 3D viewer as a ghosted out representation so you can see where your spindle is in relation to the overall machine extents. Apps like Othermill have this and ChiliPeppr will get it. Due to the disparate nature of machines out there, this library will constantly be updated and need to be online.

- Firmware version checking and upgrade. The firmware versions of different hardware releases like TinyG are changing constantly. Without being online no checking could occur of cloud variables, thus you'd lose ChiliPeppr telling you a firmware upgrade is available. ChiliPeppr is slated to support avrdude and bossac so that you can simply say "update my firmware" and it downloads the new .hex file and flashes your hardware.

- Pick and place. One of the holy grails of the circuit board makers in the CNC community is a good pick and place system. This requires hardware and software to work in tandem. There's no good standard software today and likewise there's no standard hardware today. To get there we need to iterate a lot as a community. We need machine vision. We need extended feature sets. We need a component library. We need a UI that is simple. We need Eagle BRD import scripts. We are just 5% of the way to a solution. We have to focus on adding code and not focus on being offline or we'll never get there.

- On app store for ChiliPeppr. This will allow folks to better publish their own plugins. You can see an ever-growing list of plugins including Frank's ShuttleXpress jog pendant, or Ben Delarre's GPIO server, or Kevin's TinyG configurator. If ChiliPeppr were offline, the notion of publishing new plugins would be way harder or just wouldn't end up as a built-in feature. Too much time would be spent on the sub-packaging of offline versions of plugins and the update cycle and dependency management of plugins. You'd simply just have to give up on ever having an app store.

- A community wiki list of macros. People still don't know the power of macros and they will get better. An even larger library will help folks do even more. To get there folks need to be able to just click share and it's in the cloud. Offline would remove this notion.

- Laser cutting. The world of laser cutting is still in it's infancy. We need a plugin that allows you to calibrate your laser, or calculate feeds and speeds based on wattage, focal point spot size, which nanometer your laser operates in, and which material you're cutting. This requires its own set of app store plugins, and/or own workspace, and/or even new hardware. To iterate enough code versions to get there requires no blockers in the way like worrying about offline versions, dependency management, packaging, etc.

- 3D printing. There is a new board called TigerShark for 3d printing based on TinyG. There is already a new workspace forked from the TinyG workspace that is gaining new widgets specific to this board. There will be a cloud slicer engine avaialable to all users of the workspace so you don't get stuck with having to figure out what slicer to use. The slicer is os-dependent code thus its easier to just toss into the cloud than worry about packaging desktop versions.

- Smoothieware support (and others). There is no CNC or Gcode sending software that has great support for all popular boards out there. Why? I think if we had a platform that supported all of them, we would gain a better platform for folks to feel compelled to write add-on plugins and widgets because a larger userbase would use or benefit from the add-on. Therefore enabling other hardware to create a workspace, extend the work already done on ChiliPeppr, and move us all forward is paramount. If we focus on offline we lose this because we slow down the release cycle, we make forking harder, etc. It's more important to move forward than to focus on offline.

Open source nature of ChiliPeppr enables somebody in the community to create an offline version.

Now, to comment on the nature of open source. I do think if a certain group of folks want an offline version of ChiliPeppr, that this should be embraced by that group and a new open source project could get created that perhaps turns the online app into a packaged offline app. That group would have to commit to playing the cat and mouse game of removing online features, packaging the app, creating a release cycle, etc. If new online-only features get added to ChiliPeppr, this offline group would just have to get creative on how to hide/remove that feature. I think that's pretty cool if that can be achieved.

I do want to comment though, that for me, I can't ever let the offline version break my thinking or anyone else's thinking that's contributing to the mainline features of ChiliPeppr. For this reason I don't like the idea of an offline app because it could slow down people's thinking with stuff like "oh, but what about the offline version, that would break my feature..." because then we just moved backward in life.

BTW, I haven't published the open source license but I have made statements in other forums that it will follow Linux's license of GNU GPL v2. I will soon publish that in the header or footer of the site somewhere.

On paying for ChiliPeppr

I think if somebody in the community wants to create a paid-for version, then perhaps model it like the Linux community. There was and still is the core linux kernel that is open source, but we got commercial versions like RedHat for enterprise customers that wanted support. I think if we got that with ChiliPeppr it would be awesome.

I, like many contributors, have a day job and having payment for ChiliPeppr would undermine the open source nature of the core project so I think it's best to not have payments come into play for the core project. If any folks want to do payment beyond that then I fully support it and in fact think that could be a huge move forward for the community.

On the Internet and the cloud not going away

The Internet just isn't going to go away. So, for any folks who have a workshop where they haven't run wifi or Internet, what I would ask is that those folks spend the money to do it. ChiliPeppr is free software. If you had to pay for Mach3 you'd be spending real cash. Take that cash and spend it on wiring up your workshop. You'll gain all the advantages of the cloud way beyond ChiliPeppr.

My final thought is, we all have a lot of work to do in the CNC community. We are at the infancy here and I believe we've only scratched 3% of the surface. We need to make sure the least amount of hurdles stand in our way from creating the features we're all craving to be more productive and do more. Let's let our software evolve at the fastest pace possible.


Posts: 58
Joined: Sun Feb 01, 2015 1:12 am

Re: How to run ChiliPepr w/o internet (was Re: Software)

Post by sdumond » Wed Apr 01, 2015 7:11 pm

I can understand some of what you are saying, BUT NOT EVERYONE HAS INTERNET ACCESS IN THEIR SHOPS! I did not know this when I bought the tinyg, and now I have no way to operate it without a ton of hassle. The TGFX platform might have worked great had they not abandoned it. Like I said it has a lot of issues, as they have abandoned it! I still believe there is a lot of people that do not have the cloud.

I am not blaming you because chili peppr works! But like I said, if I had known ahead of time this was going to be a problem, I would have bought a controller that worked with MACH 3.

I am banking real heavy on GrblGuru and if it works, I will definitely spread the word and push for this program.

Thank you for responding to this, but I still feel the cloud is the wrong way to go. Even when we do have internet it goes out regularly and then you can't produce anything!You are banking heavily that the internet is going to work all the time. Like I said I feel this is the wrong way to go. But that is what makes this country so great is that to this point we can pretty much choose what we want to do.

Again thanks for your time.
Last edited by sdumond on Thu Apr 02, 2015 12:05 am, edited 1 time in total.

Posts: 207
Joined: Wed Jan 01, 2014 4:02 am
Location: Friendswood, TX

Re: How to run ChiliPepr w/o internet (was Re: Software)

Post by lordmundi » Wed Apr 01, 2015 11:34 pm

John, while I really appreciate you typing all that up, I can't help but shake my head at much of it. There are many examples of software that run in the browser that allow offline usage. There are also examples of cloud software that you elect when to step up to a new version (or alert you one is ready to step up to) without changing it underneath you. Also, people can self-host web applications at home, so there is no reason that you can't use logins, use a web browser and do most of the things you are talking about. And it can still reach out to the web via <script> inclusions and be connected to the cloud and check if newer versions of widgets/modules are available. Wordpress does this ALL the time.

Anyhow, you know I love Chilipeppr. But I think there is still some substantial miscommunication or something when it comes to understanding what some of these users are asking for and what you believe it means to run in the cloud. And given the architecture of Chilipeppr with JSFiddle being so central to it, I agree with you that it could be a substantial shift to make offline abilities integral to or part of CP. I think the only workaround at this point would be some sort of way to download everything and let someone self-host it, or a proxy solution that folks could use. And like you mentioned, both of those could be hard.

So, while I disagree with you on the implementation of your design goals, it's probably not worth arguing over unless we are pursuing one of those two options I mentioned which could live outside of CP.

When I get time, I'll try to work on the proxy solution. No guarantees of course. Other than that, if folks want something they can run offline in their shop, I think they will need to start looking at forking, enhancing a different product, or starting something new. None of those are bad things - in fact I'm sure it could be a lot of fun.

Posts: 115
Joined: Thu Jun 26, 2014 9:29 pm

Re: How to run ChiliPepr w/o internet (was Re: Software)

Post by jlauer » Thu Apr 02, 2015 1:25 am

Given that I've described my position and that some folks are still arguing for offline, here are the reasons I've heard folks wanting offline and I think it's worth debating their merits now.

1. Offline is needed because the user has no Internet in their workshop.
2. Offline is needed because the user simply doesn't like apps running in the browser and they feel more comfortable with a desktop app.
3. Offline is needed because the user is worried about viruses on their computer from it being online.
4. Offline is needed to be able to "freeze" the version number to ensure future jobs run perfectly because there's a fear that future updates will break stuff.

Am I missing any reasons?

Posts: 639
Joined: Tue Mar 11, 2014 1:37 am
Location: 5 miles north of Benson, NC

Re: How to run ChiliPepr w/o internet (was Re: Software)

Post by Woodworker » Thu Apr 02, 2015 11:05 am

jlauer, you don't owe anyone justification nor do you need to design and build an offline version. You have dozens of people that love your contribution, just the way it is. Please don't dilute your programming time or machining time just to placate those that want/need offline mode. My reasons are 1 and 4 but I never asked for you to build it. I just indicated that if you did I would use it and that with the current functionality it was an amazing program.
BRuce - SO2 #4798 - IC's Z axis upgrade, customized Z rail and Z motor mount, spindle Dewalt 611

Posts: 8629
Joined: Mon Apr 09, 2012 6:11 pm
Location: Pennsylvania --- south of the Turnpike, East of US-15

Re: How to run ChiliPepr w/o internet (was Re: Software)

Post by WillAdams » Thu Apr 02, 2015 11:52 am

Let's turn this around.

What would be the best option for developing a communication / control program which was:

- lightweight (suited to running on older, slower equipment and Raspberry Pis and the like)
- cross-platform (available for Linux, Windows and Mac OS X)
- easily customizable by the (naïve) user
- would be available / runnable from a single file (or small collection of files) so that it would be available off-line
- could be expanded to include both routing/milling and 3D printing (and other functions such as probing?)

I've got an idea, based on a recent finding of a very old program which was just added to the wiki, and will probably be investigating it more deeply once I've got my Ordbot up and running again (just needs calibration!), my SO3 up and running (just needs to be delivered and photographed) and am caught up at work.
Shapeoko 3XL #0006 w/ Carbide Compact Router w/0.125″ and ¼″ Carbide 3D precision collets

Posts: 639
Joined: Tue Mar 11, 2014 1:37 am
Location: 5 miles north of Benson, NC

Re: How to run ChiliPepr w/o internet (was Re: Software)

Post by Woodworker » Thu Apr 02, 2015 1:06 pm

There already is such a program and the code is inscribed on the bottom of the holy grail. ;)
BRuce - SO2 #4798 - IC's Z axis upgrade, customized Z rail and Z motor mount, spindle Dewalt 611

Posts: 8629
Joined: Mon Apr 09, 2012 6:11 pm
Location: Pennsylvania --- south of the Turnpike, East of US-15

Re: How to run ChiliPepr w/o internet (was Re: Software)

Post by WillAdams » Thu Apr 02, 2015 1:18 pm

Okay, started a new thread:

There are a bunch of programming things I'd like to do (or see done) for the project (and have never started), so we'll hash this one out and see if I can bestir myself to actually do something for once.
Shapeoko 3XL #0006 w/ Carbide Compact Router w/0.125″ and ¼″ Carbide 3D precision collets

Posts: 30
Joined: Mon Dec 01, 2014 12:41 am

Re: How to run ChiliPepr w/o internet (was Re: Software)

Post by khauser24 » Thu Apr 02, 2015 5:30 pm

In reading this thread it occurs to me (and I believe I have mentioned this before) that the most annoyed people bought a TinyG and feel betrayed because there is no offline program meant for it. That has happened because Synthetos (the company behind the TinyG) discontinued development of tgfx when they discovered ChiliPeppr. But like the TinyG, tgfx is an open source program, so discontinuing it really doesn't mean its done. It means THEY are going to continue working on it.

Folks, you CAN use tgfx, and it works offline. Better yet, you can GROW it. Now I know the majority of people with this problem are not software developers, but there are probably some who can be made interested.

I personally think Synthetos may not have thought this through completely, but they are a very small company and decided their efforts would be better-focused away from the g-code sender. I think instead of discontinuing they should simply have declared support for it would be up to the open source community. Since the program continues to exist and anyone is able to get the sources for it, that is effectively what they have done.


Post Reply