Sorry another thing came up while I was converting the CNC from OctoPrint to

Sorry another thing came up while I was converting the CNC from OctoPrint to Chilipeppr (GRBL to TinyG2). Is there a way to get the SPJS to trigger python scripts on events? (Start, Stop, Feedhold, Error etc…)

I have a status LED built from a strip of WS2818 addressable LEDs- Octo has events that can trigger other events. i.e. When a job is about to start and the spindle is about to go hot, It goes from standby (green) to flashing red. Then goes back to green. Basically an event that triggers a python script to change the LEDs.

Is there anything similar?

(I’ve seen the GPIO function but in my case, I have a script running on the RPi B+ that handles the SPI to the LEDs directly. Looking at the GPIO function in CP it’s more for turning things on and off.)

(edit - This would open up support for other things like Pushover or Growl.)

on a related note, i’m looking for a way to get a status from SPJS about which port is open. Just wanted to mention it in case this thread prompts some sort of interface to SPJS for programs running on the same machine - being able to get a status would be useful to me.

It’s all in the pub sub of each widget. So look in the upper right pull down menu of each widget because they are all self documenting. There are signals for all those events that you can tap into

I saw that, But if I am mistaken. That triggers a pin high/low per event. But does not have the ability to execute a script running locally on the remote machine?

The architecture question you need to ask yourself though is where should the logic sit? In the browser? Or on the server running spjs? For turning on leds i would say do a macro that you load each time you load chilipeppr. Have that macro tap into the pub sub events like /onplay and /onstop and send serial commands or gpio commands or call http web services on your raspi

It could be interesting to allow spjs to trigger command line activity. There are security considerations there. Do you want to add that in the git project? Or what if you deploy your own separate web services on your raspi and just call those from JavaScript?

Well the SPJS see’s whats going on. i.e. a job start, feedhold etc… So it having the ability to trigger then event would make the most since as it local to the multi-axis machine in question.

good point about security. I think as long as nothing is allowed to go to SPJS that directs the code execution (like code to run, what file to execute, etc), then it could be ok. For example, if there are specific scripts you can define in a config file for SPJS to execute on certain conditions, i think that would work.

Spjs is not supposed to have intelligence as to what is truly going on, however I’m quite open to it gaining such intelligence but that is an architecture shift. The main idea today has been that all intelligence is in the browser.

hmm… good point. I wonder if you could avoid adding that intelligence. For example, I wonder if the config file that defines the events could just be a regular expression to watch for and the corresponding event to fire. That would avoid SPJS having to know anything about the gcodes or any other type of event.

So in other words not possible. That’s bummer. I am going to miss all that stuff. I was okay with losing the pendant thinking I could add that stuff in later- But it seems like I am going to lose all stuff I’ve added to Octo for local notifications and controls.

I think all of this is MORE possible than what Octoprint provided because we are guaranteed cloud connectivity. You just have to get more into a JavaScript mindset than a Python mindset. Get into more of a “what can I do from the browser” than “what can I do from my own single desktop”. So, instead of Growl, just do a Chrome notification which is supported in Firefox as well now. For turning on LEDs do a webservice instead of a local python script. I think this is a better model because why should you have to have only one device run your CNC machine? I have lots of devices connected including an Arduino that runs my laser, another Arduino on a different Raspi that runs my solder paste dispenser, etc. I don’t want to be tied to one Raspi the way OctoPrint makes me do.

That greatly depends if all your gear is in one place. For me it’s not. The CNC is in the garage. The laser is in the basement and the 3D Printers are in my office. So they all have an localized SoC connected to them.

shrug I guess I am going to have to figure this out on my own.

i tend to agree… there are some things that feel better to do locally - things that are connected to physical hardware. I think something like the regular expression matching thing for SPJS could solve both of our problems as well as allow plenty of other things. For example, you could always send gcode comments down to SPJS, so folks could write widgets to send any sort of custom commands and have it fire pre-determined scripts on their SPJS box. For me, i’d want to wait for the open command and fire something so that my adjacent program that interfaces with my jog dial knows what serial port to command in SPJS. Anyhow, something like this seems to add flexibility for folks to customize without having to adjust any interfaces or force developers to develop on the web or anywhere else. Something to consider.

It seems to me that you’re both agreeing you need lots of different devices to be able to talk at the same time. So I think all three of us are on the same page there.

The next issue is, what’s the right architecture? I think SPJS is pretty slick in it’s basic design that any number of end-points can connect and anything sent in, is reflected back out to all end-points in real-time. That doesn’t exist anywhere else in the CNC world and especially does not exist in OctoPrint.

Ok, so we have a central way to communicate with all our end-points via SPJS. Now, if we want different implementations of logic on other devices or other end-points, like a Python script on an Intel Edison or a pendant script on a phone, that’s fine. They all just connect into SPJS and watch all the back and forth traffic. Why have SPJS do this when you could just have a Python script that listens on the websocket? Let the Python script just sit there and read all the incoming gcode reflected over to it and decide if it needs to do something special. The Python script could sit on the same Raspi as SPJS, but it should probably just listen on localhost.

On the topic of figuring this out on your own, I do think that everyone has their top priorities right now. I know Frank is big on getting a pendant server going. Riley is big on getting a firmware updater going. I’m big on getting the Eagle BRD import script completed. What’s great is that we’re all seriously contributing to this initiative right now and this software is leagues ahead of anything else now–arguably better than Mach3 in many cases.

Is there a API for the SPJS?

It’s all nicely documented on the main page of the Github project. https://github.com/johnlauer/serial-port-json-server

I recommend you open up two browser windows both pointed at http://chilipeppr.com/serialport and watch the console on the right. Then type a command in the low-level console on right, or the high-level console on left. The low-level console reflects back everything from the other browser. One idea we could do is add a new “echo” command for cross-talk across end points that is out of band from actual gcode execution, ala we don’t have to do this via gcode comments (which has been a prevailing idea).