Hey all! I’ve been poking at the Line-us’s new websocket interface for a bit and have finally published a JavaScript library that can be used in both the browser and Node.js:
It’s still quite in-progress but it works fine and makes connecting and drawing pretty simple and fun. Let me know if you have any questions or input!
Had a very quick look last night and it looks great. We’re really hoping to see people writing browser based apps for Line-us and I think this will help greatly with that. I’ll put a link to your GitHub on our programming page if that’s ok.
Just one thing you might find interesting - in the documentation you quite rightly note:
The coordinate emitted will be the machine’s position when it finishes the current command . It is not the machine’s immediate position.
The reason that we echo it back to the sender is that multiple apps can connect to the Line-us at the same time (technically four for WebSockets if I remember correctly although not quite sure what performance would be like with four), so if another app has moved the arm you can find out the current position by sending an M114. Potentially this opens up some interesting possibilities for (for example) games so would be interested to see what you all can come up with!
I’ll put a link to your GitHub on our programming page if that’s ok.
Certainly.
multiple apps can connect to the Line-us at the same time
Oooh, that is very interesting. I’ll have to test for that. Do the “buffer” mechanics stay the same eg: does each connection get to have one in-flight command and one unacknowledged command buffered?
Very happy to hear any other feedback. I need to handle Line-us’s error messages better, and do some testing and some documentation updates. I just updated things yesterday to use a more standard “0,0 is top left” coordinate grid on top of the same drawing area used by the app.
We’re really hoping to see people writing browser based apps for Line-us and I think this will help greatly with that.
I’m really jazzed about this websocket stuff. Very happy that y’all added the capability.
There’s no chance you have a Line-us emulator/simulator kicking around anywhere is there? I know it’d be overengineering things but I’ve been wishing I could connect to a simulated Line-us to run tests against.
In the meantime I’ve just been mocking up a naive js-based Line-us imposter.
Do the “buffer” mechanics stay the same eg: does each connection get to have one in-flight command and one unacknowledged command buffered?
Yes, that’s right.
Very happy to hear any other feedback.
Will do, and similarly if you find any inconsistency in the error messages you get from Line-us (and there are some I’m sure) let me know. There will be a minor firmware update in the not distant future so I can put in anything you find.
Very happy that y’all added the capability.
Thanks. We actually did it for Scratch, and didn’t really realise how useful it was until we’d done it!
There’s no chance you have a Line-us emulator/simulator kicking around anywhere is there?
Unfortunately not. Have thought about it a few times but never managed to find the time to do it.
From the docs:
The z axis is the pen height; 0 is down and 1000 is up.
If the pen is on the down position (z < 500) the pen will lift (z = 1000).
This gave me the impression that the actual 0-1000 scale of the z axis was a ruse, and anything < 500 would result in the pen being all the way down (0), and 500+ would result in the pen being all the way up (1000). This is not the case and upon re-reading i see that you never really said it is. Still, it was a point of confusion and creates some “interesting” edge cases for my library. Do you know of anybody using these variable heights?
Also it seems like I can send my Line-us a Z2000 command and create some very unhappy noises.
Hi
Having great fun experimenting and making games for Line-us using your Java Script library inside P5.js
Thanks.
Do you know of anybody using these variable heights?
Not at the moment - would love to see someone use it for variable line width with a brush pen though!
point of confusion
I’ve re-worded it so hopefully clearer now - thanks for pointing this out.
Also it seems like I can send my Line-us a Z2000 command and create some very unhappy noises.
Fix is already in the upcoming release for that one
Hey durrell! I’m glad you’re getting some use out of my library! Let me know if you have any issues / questions / input. Thanks!
We were just playing around with the library - works really well. A couple of suggestions:
For the game we’re working on we want to pause the drawing, which is fine using bot.pause() - we then want to send an immediate bot.penUp(). We managed it with _send() but in general the ability to insert a command at the head of the queue (possibly only when paused?) would be useful - will give it a bit more thought and have a stab at adding it.
On the co-ordinate system, a more general solution might be to implement G54 (which I’ve just noticed isn’t in the documentation) and let the Line-us do the scaling?
Anyway, great piece of work!
thanks for the feedback! i’m glad the library is useable by other humans.
i think it makes sense for .pause() to always do a penUp() by default. i’m not sure if the best way to do that will be using the priority features of the queue or to manually fiddle with some _send() commands after pausing. i’ll have to test things out, but i can poke at this soon.
i’ve made an issue here just for giggles: https://github.com/beardicus/line-us/issues/1
if it works as expected i’d probably add an optional priority parameter to the send() command and pass it through to the queue. or maybe just use a simple flag to skip the queue.
On the co-ordinate system, a more general solution might be to implement G54 (which I’ve just noticed isn’t in the documentation) and let the Line-us do the scaling?
oh, i didn’t know this was possible. i’ll tinker with it… there’s not much generic reprap/grbl documentation re G54 so i’m not sure it’ll cut it. i need to be able to flip the Y axis, for instance, not just perform a simple translation. any documentation/insight you have would be useful.
i think it makes sense for
.pause()to always do apenUp()by default.
this is done in 2.0.0! let me know if you have any issues.
i did not implement a generic .sendImmediately() method to skip to the front of the queue, but i think i figured out how to do so without breaking the world. the ability to send commands while the queue is paused would be a bigger hurdle.
there’s not much generic reprap/grbl documentation re G54 so i’m not sure it’ll cut it
I’ve updated the GCode Spec to include the G54. Now way t reverse just one axis (a negative S would probably reverse both. I can add in the next firmware though as it seems like a generally useful feature.