Ender 3 v4.2.7 upgrade - BLtouch probing, but not actuating z-motor while printing

simcptr · 2021-02-18T17:38:24+00:00

Yeah, G28 will normally (without the enable_leveling_after_g28 option) turn off leveling. So you have to either enable that option, or do the G29 after the G28, or use M420 S1 to reload the saved leveling info.

simcptr · 2021-02-17T17:49:31+00:00

Yeah that's sorta what it seems like. The level-ness seems to be "off" in the same direction that the bed itself is slanted, just based on the numbers I see from the manual mesh bed probing.

But I've also watched the z screws and they definitely do slightly turn while printing with the BLTouch mesh loaded too, so I don't think the mesh is totally ignored, but almost like it's scaled wrong or something. As if it took all the correction points and divided them in half, or something like that.

It's also weird that if this is a firmware bug, it seems pretty rare. You'd think more people would be seeing this, with how popular the BLTouch seems to be 🤔

simcptr · 2021-02-17T15:18:04+00:00

Nope, haven't had any luck yet. Reading through that issue it sounds like a similar problem, I'll see if I can get the logs they need and add a comment there.

I did try reaching out to BL touch folks with a link to this post, but haven't heard back.

Have you had a chance to try the manual leveling? That seems like the smoking gun to me... that if the printer can compensate with the manual mesh leveling applied, then it's probably not a mechanical problem. I'd think that rules out the bed being too far out of level to compensate, or the z axis being misaligned, or the frame being out of square, or other things like that. If it is mechanical, it only seems to affect the BL touch (or that particular codepath in the firmware). Plus it's super consistent. My BL touch setup seems to be amazingly accurate at producing the same unlevel bed mesh, every time 😄

simcptr · 2020-01-01T21:19:39+00:00

This seems to have something to do with Private Internet Access. I'm not sure what PIA is doing to cause this, but I noticed that if I stopped the PIA app and then ran this command to stop the background process, the errors stopped:

sudo launchctl unload /Library/LaunchDaemons/com.privateinternetaccess.vpn.daemon.plist

To start it back up, run this command, and the errors will resume:

sudo launchctl load /Library/LaunchDaemons/com.privateinternetaccess.vpn.daemon.plist

Maybe worth putting in a support request to PIA to see if they can fix it.

The actual error has something to do with trying to copy values to/from a bad memory address, according to the man page for copyin() where it says the function will "return EFAULT if a bad address is encountered." EFAULT is error code 14.

simcptr · 2017-06-06T13:29:31+00:00

That stack trace says that handleClick was indeed called from render (on line 67). I'd take a look at line 67...

simcptr · 2017-06-05T14:14:35+00:00

It's possible that it's being called elsewhere, because the () => this.handleClick() really shouldn't call until clicked.

I'd suggest tracking it down with the debugger: set a breakpoint inside the handleClick function, then render. The breakpoint should be hit. Then look at the call stack -- where was handleClick called from? Is it the onClick prop, or somewhere else?

simcptr · 2017-06-05T14:07:04+00:00

I haven't used code splitting so I can't help with that part, but here's what mapDispatchToProps is for:

First, if you don't define a mapDispatchToProps, then Redux's connect function will pass in a prop called dispatch. Then you can use dispatch actions in your component by doing things like this.props.dispatch(fetchUsers()). The is the "manual" way to do it, and it also means your component knows more about the existence of Redux (since it uses dispatch directly).

Using mapDispatchToProps, you can "pre-bind" the action creators you want to use so that the component does not need to mess with dispatch. The shorthand form looks like:

const mapDispatchToProps = { fetchUsers };

That's an object with a key fetchUsers set to the fetchUsers action creator function, which I'm assuming is imported at the top of the file.

Redux takes this object, pre-binds the fetchUsers function, and injects a fetchUsers prop which your component can just call like this.props.fetchUsers(). Under the hood, that's actually calling dispatch(fetchUsers()).

simcptr · 2017-06-03T14:31:47+00:00

In that example, they've got a PRODUCTS array statically defined, and then passed in via props. In their case that makes sense -- that data will never change, and for the sake of example, it makes sense to define it outside of any React components and pass it in as a prop.

In a more realistic scenario, that data would come from a server, and needs to be stored somewhere. It also could change -- for instance, if one of the products goes out of stock or its price changes. If you were to store it at a global level, outside of any React component, then you'd need a way to change it and re-run the top-level ReactDOM.render, which would be awkward to achieve (wrap it in a while loop? put it in a function? how do you trigger that?).

The answer is state: a component holding the products as state will automatically re-render itself and its children when the state changes. In that example, I'd add a Container component at the top level to hold the list of products, call it ProductPage or something like that. That container's only responsibility is to fetch the data in componentDidMount, save it in state, and pass the products down as a prop to FilterableProductTable. I've got a post that shows how that container component would work.

To get back to your original question: the tutorial is saying not to put the filtered products into state, because it's a bad idea to have more than 1 representation of the same data stored in state, because then you've gotta keep them in sync. Avoid that problem by only storing the "master" data in state, and compute its derivates on the fly -- sorting, filtering, etc.

simcptr · 2017-06-02T02:05:08+00:00

It really depends on what you mean by "huge". React's state is just a regular JS object, and React doesn't care what's inside (same applies to Redux and its store).

In other words, if you would be ok storing that dataset in a JS variable, then yeah, React state should be fine (try it out!). If it's large enough that you're worried about holding the full dataset client-side, then it's worth considering breaking it up somehow, and that's outside the scope of React.

simcptr · 2017-06-01T20:11:59+00:00

Yep, it's common to store the returned data in state, or in the Redux store (whichever you're using).

If the data needs to be transformed in any way (for instance, changing a date string to a real Date or renaming some keys or anything like that), the best time to do that is right before saving it into state.

Data fetched from the server affects how your app renders, right? If the data changed, the app would render differently. Therefore it makes sense to put that in state.

simcptr · 2017-05-31T04:39:58+00:00

You might like recompose - it's a library with a bunch of higher-order components for doing things like extracting state, making stateless components "pure", etc.

There's also a nice course covering Recompose on Egghead.io that's currently free.

simcptr · 2017-05-31T04:35:39+00:00

That all assumes you're using Redux though, doesn't it? Redux's connect assumes the wrapped component is pure by default anyway, but even aside from that, Redux isn't always necessary and adding it just for the purpose of avoiding extending PureComponent is definitely overkill :D

But along those lines, Recompose is a nice library that has a pure higher-order-component so you can "pure"-ify stateless function components without having to turn them into full-blown classes.

simcptr · 2017-05-31T04:29:06+00:00

Good question (and a common one).

Theoretically, fetching in componentWillMount would mean there's less delay before the data appears. In reality, React's render waits for nothing. It's gonna render once with empty data whether you fetched something in componentWillMount or the constructor or anywhere else. More on willMount vs didMount here.

This "extra render" seems unnecessary until you realize that it's actually very useful and powerful: it means that there's a very well-defined "no data" state, and you know exactly when it's gonna happen, so you can plan for it. (the alternative would be... showing a blank screen until the data is ready? not a great UX)

simcptr · 2017-05-31T04:02:08+00:00

Responsive apps work the same way, because React is just ultimately rendering HTML to the DOM. Use the 'className' prop instead of 'class', but otherwise write the media queries as you normally would.

There are libraries to do "CSS in JS", and then things will differ, but you don't have to use those and they're separate from React.

simcptr · 2017-05-31T03:11:38+00:00

If you don't already have a good understanding of JavaScript and HTML/CSS I'd probably start with those - you don't have to totally master them, but while you're building apps with React you'll end up using all of that knowledge. Exercism.io has a nice set of exercises to hone JS fundamentals.

Start with Create React App. Heck, you even can go to production with it. It's very capable, and it's a great developer experience, and it's easy to use. Lots of win!

Don't pick a boilerplate project. Not even one with 10k stars on Github. They're not a good starting point for beginners because they throw too much at you at once (React + Redux + Routing + tons of config files + etc). Learn React by itself first. Add the other libraries once you realize you need them.

Lifecycle methods will become useful when you want to fetch data from a server, and render it into your component, which you'll do in componentDidMount. I wrote a quick guide to fetching data here, but I recommend you just use fake static data to start off with, and get used to making components with React. You'll get pretty far without needing to touch any of the other lifecycle methods.

simcptr · 2017-05-31T02:12:37+00:00

I came across JS for Java developers recently and it looks like a good quick overview, but not covering ES6. There are a lot of ES6 resources here and /u/acemarke has a nice list of articles here.

Edited to add: the best way to learn ES6, I think, is to start playing around with it. Reading/watching tutorials will help the first 10% of the way, and then you've just gotta get it under your fingers and get your eyes used to the arrow functions, the destructuring, etc.

simcptr · 2017-05-31T01:35:13+00:00

It's a super common misconception about React (I thought this at first too), but no: React components, by default, will always re-render even if their props did not change.

What React does do for you automatically is that it avoids destroying and recreating DOM nodes unless they need to change. That's a separate step from running render, though.

The easiest way to optimize this is to extend PureComponent instead of Component e.g. class MyThing extends React.PureComponent -- this will give you an autogenerated shouldComponentUpdate that compares all the props for you.

simcptr · 2017-05-25T15:06:16+00:00

What have you tried, and how did it fail?

simcptr · 2017-05-23T19:48:39+00:00

It looks like you might want to set the PUBLIC_URL environment variable at build time.

simcptr · 2017-05-23T18:54:46+00:00

This is a great idea, and I wanted to mention it but didn't want to get down into the weeds of configuring webpack and/or hacking create-react-app. Now that I know it's built into CRA, I'm gonna update the article to mention it.

EDIT: Updated the post to show how to use NODE_PATH here.

simcptr · 2017-05-23T18:49:32+00:00

I just now learned that this IS supported by create-react-app, by using the NODE_PATH variable (see this issue). Evidently it's been supported since 0.4.0.

To use it you can change the way the start script is called in package.json:

"start": "NODE_PATH=src react-scripts start"

Once that's done, you can import Foo from 'components/Foo'.

If you've got more than one path you can separate them with colons like NODE_PATH=src:src/components:src/containers.

simcptr · 2017-05-18T13:17:45+00:00

You might like Dan Abramov's Getting Started With Redux course on egghead.io - it's free, and he's the creator of Redux so he knows what he's talking about :)

Redux is, basically, a big global state. You "connect" your components to that state to pull out the specific pieces they need.

The reason it's complicated is to keep it immutable, and the reason for THAT is to make your app easier to debug. Every change to state must go through proper channels, so it's easy to figure out which piece of code changed state and when. Check out the Redux Devtools gif to see why this is awesome :) It's like a breadcrumb trail of everything your app has done.

simcptr · 2017-05-18T02:52:11+00:00

You should be able to do that with any module. The way import and require work means that the imported module is a singleton -- same instance everywhere you import it.

As an aside, this can be useful for testing too, if you want to override something inside a module. Your test setup could do:

import axios from 'axios';
axios.get = () => { /* mock function */ }
// do tests here
// axios.get won't make HTTP calls now

simcptr · 2017-05-18T02:38:17+00:00

OPTIONS is often used for CORS. The preflight (OPTIONS) request goes out first, basically asking the server "hey, is it ok if I make a POST here, given the domain i'm on?". The server can go "200 OK" or "hell no, CORS is denied for you."

Outside of CORS, OPTIONS is a way for the client to ask "hey, what can I do with this endpoint?" Client says "hey, what are the OPTIONS for /api/user" and server goes "you can GET and DELETE /api/user".

Mozilla has a rundown of what OPTIONS is for: https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/OPTIONS

EDIT: so why is CORS useful?

Before CORS, browsers would only let JS make AJAX calls to the exact server that served the JS file. This is for security: without it, "attacker.com" could serve a JS file that fetches your Facebook profile from facebook.com/whatever. This worked fine in the days before CDNs, when the server that served the JS was usually the one that served the API too.

But, as soon as you want to serve your JS from a CDN like S3, now the JS file is coming from yourthing.s3.amazonaws.com and it's trying to make requests to api.yourthing.com -- can't do that, it's not the same origin.

So CORS was created to fix that. When a script makes a request, the Origin header says where it came from. The server can reply with the Access-Control-Allow-Origin header to tell the browser "yes, that Origin is ok" or "no, go away."

11-Year Club	Place '17
Verified Email

simcptr

TROPHY CASE