Help with obtaining firmware config (select params)

[ghost]

trafficstars

I am working on another frontend where I intend using lw.comms-server as well.

In this frontend, I want to obtain the Smoothie config file and then parse it. In my old project CoPrint, i used (which should not be used) MSD to access the Config file from SD over nodejs-fs: See https://github.com/openhardwarecoza/CoPrint/blob/9b602c256c2fab10158bd9033d4c14ab33bbdccc/server-smoothie.js#L192-L205

Of course that being the wrong way, i am now trying to do the same over Serial. using Smoothie command 'cat /sd/config' works beautifully, but instead of getting the file as a whole, i am getting each line as a seperate event. This makes parsing it much harder

I almost have to do

if ( data.indexOf('alpha_steps_per_mm') === 0 || data.indexOf('beta_steps_per_mm') === 0 || data.indexOf('gamma_steps_per_mm') === 0 || data.indexOf('x_axis_max_speed') === 0 || data.indexOf('y_axis_max_speed') === 0 || data.indexOf('z_axis_max_speed') === 0 || data.indexOf('acceleration') === 0 || data.indexOf('z_acceleration') === 0 || data.indexOf('endstops_enable') === 0) {...}

for each value i want to work with... yikes.

@cprezzi any ideas how I can go about reading the file using 'cat' and get it in ONE event?

[ghost]

(Goal: In the end i assemble it into a smoothieParams object:

with the eventual goal of then sending set-config commands back to update the popular settings for noobs

[ghost]

For what its further worth, I get the output of '$$" from Grbl in seperate events too, but that very useful "$number..." is easy to get with

 } else if (data.indexOf('$') === 0) {
           grblSettings(data)
       }

[cprezzi]

You get it line by line, because lw.comm-server get linebreaks from smoothieware. I think cat is the wrong way to do it, because there are no start or end of file marks.

Instead, you could read value by value with config-get and change a param with config-set.

[cprezzi]

This should be easy to implement as you anyways have a structured array.

[ghost]

Thanks!

[ghost]

I think cat is the wrong way to do it, vs ...

[cprezzi]

Hm. didn't see that. There is no such hint in smoothiehappy api (https://lautr3k.github.io/smoothie-happy/docs/function/index.html#static-function-cmd_config_get) and I think @lautr3k is also using it for his new configuration dialog.

[ghost]

Isnt smoothiehappy still just ethernet?

On Aug 4, 2017 4:06 PM, "Claudio Prezzi" [email protected] wrote:

Hm. didn't see that. There is no such hint in smoothiehappy api ( https://lautr3k.github.io/smoothie-happy/docs/function/ index.html#static-function-cmd_config_get) and I think @lautr3k https://github.com/lautr3k is also using it for his new configuration dialog.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/lw.comm-server/issues/46#issuecomment-320258113, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr26skdMFUyxnxTu7ZrHx5sT0w93Hgks5sUyV_gaJpZM4Os7tQ .

[cprezzi]

Yes, I think so.

[cprezzi]

In the smoothie code I found that if the limit param of cat is -d we should get a eof at the end of the file :) https://github.com/Smoothieware/Smoothieware/blob/edge/src/modules/utils/simpleshell/SimpleShell.cpp#L380

But we still need to make sure the queue is empty and all timers are off before sending the cat command.

[cprezzi]

What do you think about lw.comm-server providing a command "getFirmwareConfig" which delivers a complete json object with all config parameters?

The app could then dynamically create a form with all settings. It should also be possible to embed all field options in the json object. Something like:

{ 
    laser_mode: 1,
    laser_mode_options: [
        1: On, 
        0: Off
    ]
}

This way, the app (frontend) can stay firmware independant.

[ghost]

I would love that. Didnt want to intrude though as that looks like a lot of work. Would be especially cool if its cross-firmware. Ie same param name whether its grbl or smoothie.

On Aug 4, 2017 4:37 PM, "Claudio Prezzi" [email protected] wrote:

What do you think about lw.comm-server providing a command "getFirmwareConfig" which delivers a complete json object with all config parameters?

The app could then dynamically create a form with all settings. It should also be possible to embed all field options in the json object.

Something like:

{ laser_mode: 1, laser_mode_options: [ 1: On, 0: Off ] }

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/lw.comm-server/issues/46#issuecomment-320265770, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr2-Ed6ID6T37ks6Ut6QcMP3Yw3goGks5sUyyXgaJpZM4Os7tQ .

[cprezzi]

I think it's hard to find parameter names that match every firmware (because they are so different), but that wouldn't be needed if the frontend form is created dynamically with the names & options in the json object.

[cprezzi]

I know this could be less flexible for a frontend (for adding help or designing super nice tabbed forms).

[ghost]

Reading them would be different, but presenting them could be the same. X steps per mm is x steps per mm, whether its then in the backend alpha_steps or $120 - the frontend doesnt need to know (;

On Aug 4, 2017 4:42 PM, "Claudio Prezzi" [email protected] wrote:

I think it's hard to find parameter names that match every firmware (because they are so different), but that wouldn't be needed if the frontend form is created dynamically with the names & options in the json object.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/lw.comm-server/issues/46#issuecomment-320267070, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr25E3XPrxnOGXvP7q_Lwm3cw7kHdMks5sUy3QgaJpZM4Os7tQ .

[cprezzi]

That's correct, but wouldn't it be confusing for a user, if the param in the frontend doesn't have the same name like in the config file?

[ghost]

Sent you a gif on g+. The goal here is to get newbz to configure firmware. Without having any understanding of params. Configure an Axis. The app takes care of the detail behind the scenes. It could be useful in any frontend. I dont want it to do everything. Just those basics you always do on every machine. Setup stepspermm, acceleration, homing and maybe tool (spindle /laser) - the basics to get you from first power on to running a basic sample gcode in 5 min or less

On Aug 4, 2017 4:50 PM, "Claudio Prezzi" [email protected] wrote:

That's correct, but wouldn't it be confusing for a user, if the param in the frontend doesn't have the same name like in the config file?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/lw.comm-server/issues/46#issuecomment-320269004, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr22iwe0NoHTgPMbi79LrdxRd4NEmGks5sUy-tgaJpZM4Os7tQ .

[cprezzi]

Ok. Let me think about this over the weekend. Probably I get flashed with a genious solution ;)

[cprezzi]

Could you write down a complete list of params needed and how they map to Smoothie and Grbl params?

[ghost]

(: i'll leave you to it. I think it would be useful on a lot of applications.

(: i also have a mad suggestion for lw.comm-server.2 : state as json (instead of all these random events to track, imagine a single event every couple ms with queueCnt, pos, runstatus, connectStatus, overrides, etc all in one object! Back when i did the first lw comms i didnt know objects yet. Now i f*ing love em!

On Aug 4, 2017 5:01 PM, "Claudio Prezzi" [email protected] wrote:

Ok. Let me think about this over the weekend. Probably I get flashed with a genious solution ;)

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/lw.comm-server/issues/46#issuecomment-320271604, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr22JFsh0ftKzWLx6sGWd60dzS1Vtkks5sUzJRgaJpZM4Os7tQ .

[ghost]

Sure! I will do!

On Aug 4, 2017 5:03 PM, "Claudio Prezzi" [email protected] wrote:

Could you write down a complete list of params needed and how they map to Smoothie and Grbl params?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/LaserWeb/lw.comm-server/issues/46#issuecomment-320271989, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr20Cql-szH5e7kPJTJZUlqUaikRGRks5sUzKqgaJpZM4Os7tQ .

[cprezzi]

Remember that I also have implemented a firmware feature list (https://github.com/LaserWeb/lw.comm-server/wiki/Firmware-feature-list) which could complement the settings feature.

[ghost]

https://github.com/LaserWeb/lw.comm-server/issues/47 touches on the new object way mentioned in https://github.com/LaserWeb/lw.comm-server/issues/46#issuecomment-320272659

The configuration i am interested in (for now) is:

configuration: {
      x_steps_per_mm: 0,
      y_steps_per_mm: 0,
      z_steps_per_mm: 0,
      x_acceleration: 0,
      y_acceleration: 0,
      z_acceleration: 0,
      x_max_rate: 0,
      y_max_rate: 0,
      z_max_rate: 0,
      x_axis_length: 0, // Max lenght of axes: Used for soft limits in grbl and smoothie - also maybe useful to autodraw grid size
      y_axis_length: 0, // Max lenght of axes: Used for soft limits in grbl and smoothie - also maybe useful to autodraw grid size
      z_axis_length: 0, // Max lenght of axes: Used for soft limits in grbl and smoothie - also maybe useful to autodraw grid size
      x_homing: 0, // 0 = none, 1 = min, 2 = max
      y_homing: 0, // 0 = none, 1 = min, 2 = max
      z_homing: 0, // 0 = none, 1 = min, 2 = max
      x_home_invert: 0, // 0 = none, 1 = inverted
      y_home_invert: 0, // 0 = none, 1 = inverted
      z_home_invert: 0, // 0 = none, 1 = min, 2 = max
      x_dir: 0, // 0 = normal, 1 = inverted
      y_dir: 0, // 0 = normal, 1 = inverted
      z_dir: 0, // 0 = normal, 1 = inverted
      x_current: 0, // grbl-lpc and smoothie
      y_current: 0, // grbl-lpc and smoothie
      z_current: 0, // grbl-lpc and smoothie
      tools: {
        bed: true, // not really scoped to configure from here... but rather used in frontend to configure showing options related
        e0: true, // not really scoped to configure from here... but rather used in frontend to configure showing options related
        e1: false, // not really scoped to configure from here... but rather used in frontend to configure showing options related
        laser: false, // not really scoped to configure from here... but rather used in frontend to configure showing options related
        spindle: false // not really scoped to configure from here... but rather used in frontend to configure showing options related
      },