Nope, the USB booting is done after MMC2 booting (on which the bootloader is contained) so unless you mess up the bootloader, it will try to boot your system instead of the USB booting.
And most likely, if you messed with python code, linux is starting fine. It's just that the display cannot run because other parts fail. As long as you don't mess up the griffin.system service, you should still be able to ssh into the machine and fix up your mistake.
LOL daid, that's exactly the service I did mess up.
And manual says usb otg can be ised to ssh by I wasn't able to do it so I bought the usb/serial one and got in to fix my error.
Point 2.5.4 manual
That won't work with our image, due to the USB port being configured differently. I thought you where talking about: http://linux-sunxi.org/FEL/USBBoot
But do note that putting any image on an micro sd card and putting that in does boot from that. So that's always a recovery path. Even if you use the stock Olimex image to boot and fix our installation from there.
1
Hi Daid, welcome back I have missed you too 
And many thanks for the time you put into this. It is greatly appreciated!
Just did a minor correction, I misinterpreted information about shipping, shipping starts somewhere in November. So, no printers by Friday. Guess I was a bit too enthusiastic about things.
:-) Not by Friday? Damn... and I thought the weekend is safe and I have to get again my wife out of the house for party... ;-)
Great to have you back, Daid - missed you too...
question!
if i replace the stepper motors.. could I still do this:
create a new gcode file, and insert
M92 E492.45
then M500 ?
i could do this on the UM2..
Nope, that is not supported. You need to change the machine configuration file for that.
Nope, that is not supported. You need to change the machine configuration file for that.
cool cool.. pretend i'm stupid and did not pay attention.. do i just SSH in and change a config file somewhere?
Yes, the main config file is located at /usr/share/griffin/griffin/machines/jedi.json
Yes, the main config file is located at /usr/share/griffin/griffin/machines/jedi.json
i need to put my machine in developer mode to allow ssh right.
Yea dev mode on and ssh root@your-ip password the name of the brand
Edited by GuestHey guys! So just to make sure I understood correctly. To change/turn off the LEDs I add the M142 RxxxGxxxBxxxTx code after the header (not in it).
Hey guys! So just to make sure I understood correctly. To change/turn off the LEDs I add the M142 RxxxGxxxBxxxTx code after the header (not in it).
Changing the color only works on UM3 as other UM's only have single color LEDs.
.
Hey guys! So just to make sure I understood correctly. To change/turn off the LEDs I add the M142 RxxxGxxxBxxxTx code after the header (not in it).
doesn't matter where you put it, but put it after the header anyway.
M142 is for the case leds. (has no T parameter) and has rgbw parameters (note: lowercase!)
M143 is for the head leds.
There is an API for the case leds that will work in future firmware version 3.5.x
Hey guys! So just to make sure I understood correctly. To change/turn off the LEDs I add the M142 RxxxGxxxBxxxTx code after the header (not in it).
doesn't matter where you put it, but put it after the header anyway.
M142 is for the case leds. (has no T parameter) and has rgbw parameters (note: lowercase!)
M143 is for the head leds.
There is an API for the case leds that will work in future firmware version 3.5.x
Alright! Thanks! So I'm guessing in order to turn off the LEDs just input the code for the color black, right?
Yes. In the future, M142 will change to M142 H[hue] S[saturation] V[value]
I've submitted that patch for review yesterday. Will be most likely in the December firmware update.
As right now, the M142 bypasses the whole system and directly sets the leds. Which means the "led subsystem" as no idea that you did that. And the API values also do not update.
We are using HSV instead of RGB because that is a more natural way to work with colors. And you can dim the lights without changing the color way more easily.
Edited by Guest
1
Yes, the main config file is located at /usr/share/griffin/griffin/machines/jedi.json
Daid;
if I change this file, will it be overwritten with a firmware update?
also, if i wanted to reverse the feeder, is that possible?
Edited by Guestalso, if i wanted to reverse the feeder, is that possible?
If not you can always do it hardware wise, just switching 2 wires on the stepper i believe.....
if I change this file, will it be overwritten with a firmware update?
also, if i wanted to reverse the feeder, is that possible?
Edited by Guest
1
The motor might reverse if you put in negative E steps. But that could also break things, didn't try that.
Planning to make it easier to have a custom json file. This also helps us internally on various experimental machines. I took a quick look at doing this today, but the code was a bit more complex then a quick patch.
2
The motor might reverse if you put in negative E steps. But that could also break things, didn't try that.
Planning to make it easier to have a custom json file. This also helps us internally on various experimental machines. I took a quick look at doing this today, but the code was a bit more complex then a quick patch.
you are the best. next time i'll bring you beer.
also, is there a simple way I can get printer statistics ? like hours printed witha core?
also : is there a way to easily change the current to the stepper motors?
Edited by Guestyou are the best. next time i'll bring you beer.
also, is there a simple way I can get printer statistics ? like hours printed witha core?
also : is there a way to easily change the current to the stepper motors?
Printer stats will be added in the API on a firmware update. We are already collecting things, but they are not yet exposed.
Currently the motor current is hard-coded in griffin/printer/controller.py
ArunC posted a topic in UltiMaker Cura,
.thumb.jpeg.0b7a05eafc09add17b8338efde5852e9.jpeg)
Dustin posted a topic in Firmware,
Recommended Posts
Top Posters In This Topic
17
15
7
4
Popular Days
Oct 19
25
Oct 20
8
Oct 26
7
Feb 23
3
Top Posters In This Topic
Daid 17 posts
neotko 15 posts
korneel 7 posts
3dprntz 4 posts
Popular Days
Oct 19 2016
25 posts
Oct 20 2016
8 posts
Oct 26 2016
7 posts
Feb 23 2024
3 posts
Popular Posts
Daid
Missed me? I know you did. - As the Ultimaker 3 is now known and will be shipping out towards people and, (don't quote me on this one) hopefully be in the hands of users by FridayNovember.
neotko 1,417
I don't think there's a need for SD cards for that. The USB plug on the front of the machine connects directly to the miniusb port, the documentation shows that is posible to use it as boot. They just need to make a system check so when the machine turns on, while pressing the wheel (for example) it forces a USB check and firmware install if the USB drive has the firmware files on it. Of course, that system restore should be a check that loads before any other service, so it can have a fast/easy factory restore.
I think resellers should just buy the 12€ cable if they have linux know-how to debug failing parts. Is quite un-intrusive and easy to do. Ofc, the UM3 already have a really good DUMP LOG that shows almost everything that happens or doesn't happen on the machine.
Of course, with the SD boot img to burn on a SDcard, it could be much easier to play with the little board and do experiments without risk of bricking the linux boot.
Edited by GuestLink to post
Share on other sites