Zeroing nuisance - confirmation first?

KGN · April 5, 2022, 2:38pm

Hey folks, a couple things to address here,

1) RE “Set” being more prominent than "Go to"

We’ll continue to collect feedback about this, but for the time being we’re going to leave it as it is. Way back in the early releases, we actually had these swapped (ie Go To was the bigger button, Set was the smaller one) and the most common piece of feedback we received was that this was backwards and we reversed them. It’s clearly something that maybe a little more subjective as to what the most important/common action to take is (do you set zero more than go to? Do you jog over using Go To? etc).

It might just be that this area as a whole needs a redesign in terms of visual clarity if people are “slow to decide what to click” or consistently press the wrong action. We’ve tried to stay consistent with the colour scheme of “solid blue results in the machine moving” throughout the main UI as a secondary indicator of what each button does, but maybe that doesn’t work in this case.

We also might just end up adding a preference for button order, but I think some redesign might be likely since we’ve had this conversation before internally about the design of that widget. For the time being, however, we’re going to leave the functionality where it is to prevent confusion for the greater number of users.

2) "Software defaults to P1 after every path is completed"

This statement doesn’t 100% track with implementation and I’m going to ask you to follow up on some things here.

“Stopping” a job (with the red stop button) issues a board reset command which results in all modals going back to default (including G54/P1). In the next release, if you stop a job, after the reset it will return you to whatever WCS you were in previously (so if you ran a job in G56 and stopped it using the red button, after the reset gSender will issue a G56 command to get you back into the previous WCS). We’ve had a change of opinion after internal discussions on this and want to remove this as a possible pain point for users who do use different WCS.

“Job completing” (a file runs through to the end) does not reset the board, so your WCS should not change, which is leading to my confusion - I can run multiple jobs in a row in whatever WCS I want and don’t see my WCS changing on Pgm End. Nothing in the codebase resets WCS by itself - relevant events and code below. The gist is that when the Sender determines the program is finished, it emits an ‘end’ Event. The controller, on receiving an ‘end’ event, sets the finishTime, and eventually sends a “stop” command to rewind the program. At no point is the board reset or modals changed.

github.com

Sienci-Labs/gsender/blob/1a4ef0145d8ab7f28c3d31c0abe26633574b2586/src/server/lib/Sender.js#L410

    
      
          
          
    // Elapsed Time
              this.state.elapsedTime = now - this.state.startTime;
          
          
    // Make a 1 second delay before estimating the remaining time
              if (this.state.elapsedTime >= 1000 && this.state.received > 0) {
                  const timePerCode = this.state.elapsedTime / this.state.received;
                  this.state.remainingTime = (timePerCode * this.state.total - this.state.elapsedTime);
              }
          
          
    if (this.state.received >= this.state.total) {
                  if (this.state.finishTime === 0) {
                      // avoid issue 'end' multiple times
                      this.state.finishTime = now;
                      this.emit('end', this.state.finishTime);
                      this.emit('change');
                  }
              }
          
          
    return true;
          }

github.com

Sienci-Labs/gsender/blob/1a4ef0145d8ab7f28c3d31c0abe26633574b2586/src/server/controllers/Grbl/GrblController.js#L453

    
      
          
          
    this.connection.write(line + '\n');
              log.silly(`> ${line}`);
          });
          this.sender.on('hold', noop);
          this.sender.on('unhold', noop);
          this.sender.on('start', (startTime) => {
              this.actionTime.senderFinishTime = 0;
          });
          
          
this.sender.on('end', (finishTime) => {
              this.actionTime.senderFinishTime = finishTime;
          });
          
          
// Workflow
          this.workflow = new Workflow();
          this.workflow.on('start', (...args) => {
              this.emit('workflow:state', this.workflow.state);
              this.sender.rewind();
          });
          this.workflow.on('stop', (...args) => {

github.com

Sienci-Labs/gsender/blob/1a4ef0145d8ab7f28c3d31c0abe26633574b2586/src/server/controllers/Grbl/GrblController.js#L817

    
      
              return;
          }
          
          
// ? - Status Report
          queryStatusReport();
          
          
// $G - Parser State
          queryParserState();
          
          
// Check if the machine has stopped movement after completion
          if (this.actionTime.senderFinishTime > 0) {
              const machineIdle = zeroOffset && this.runner.isIdle();
              const now = new Date().getTime();
              const timespan = Math.abs(now - this.actionTime.senderFinishTime);
              const toleranceTime = 500; // in milliseconds
          
          
    if (!machineIdle) {
                  // Extend the sender finish time
                  this.actionTime.senderFinishTime = now;
              } else if (timespan > toleranceTime) {
                  log.silly(`Finished sending G-code: timespan=${timespan}`);

What may be happening is that you have some code in your “Program Stop” event in settings that is changing modals/WCS, since that code is run a) if you stop using the button as well as b) the program ends naturally. If this is not the case, could you send a video/screenshot of your console output when a toolpath completes so I can have a better idea of what’s going on for you - we can’t recreate it on our end.

Cheers,
Kevin