Nice! PLA? Whats your sanding routine like? I’ve not done much sanding on finished parts yet.

This was ABS, as that’s predominantly what we used at work, where i snuck in the print.

This was my first time finishing it, using as a test more than anything. When with 120 on an orbital and then 240. Then sprayed two coats of run of the mill black spray paint. It would take some bonds work to really get rid of some of the layer lines, but overall for the 30 minutes of work i think it elevates it enough to be worth it.

3 Likes

I’ve finally finished my grid and trying to hook it up to the fates, but none of the instructions in this thread, whether they be scripts or a series of commands and modified config files seem to get me going with the latest norns firmware (by which i mean ./waf complains about missing files - what am i missing?

thanks for all the great work by the way, building a fates and neotrellis grid really hooked me on DIY and I even have a proper workshop now :slight_smile:

maybe because i had used oscgrid inthe past?

Update:

I had to use the norns wscript unmodified and the noreyko device_monitor.c

… and I had also forgotten to run lua unload.lua from oscgrid

The recent Fates system updates include the device fix hack for the Neotrellis grid. You should not have to change anything.

Otherwise if you do recompile norns you need to include sub modules - so I’ll check the documentation about that and try to make sure it’s up to date.

2 Likes

I missed that the latest fates included the changes - I probably ended up just doing a bunch of manual steps to end up in the same place i started :sweat_smile:

1 Like

I’ve been experimenting with an 8x8 one of these using the Adafruit kit with Feather M4 Express. It’s working using @okyeron’s compiled code, and with my own version after I figured out the TinyUSB library hacks. The grid-test runs perfectly on Fates, Loom looks good, etc. Thanks for making this possible!

However, running Awake on Fates, the grid LED update doesn’t seem to work quite perfectly: only the top line of LEDs ever lights. It seems as though the code that resets the LEDs all off with every refresh executes before the other LEDs get a chance to light up. (Edit: I don’t think that anymore; see REPL investigation below)

Is this just me? Something to do with the Feather code? Or Awake itself? I can get things to behave a bit better by hacking the Awake script but wondered where the issue really lies.

Edit: looks more and more like a bug somewhere. I’ve been playing with the REPL.

g=grid.connect()
g:all(0)
g:led(1,1,10)
g:refresh()

behaves as you would expect, lighting the first LED and switching all the others off. But for other rows e.g.

g=grid.connect()
g:all(0)
g:led(1,2,10)
g:refresh()

the LED does not come on. Inserting an additional g:refresh() after g:all(0) makes it work.

Any ideas where to look to figure this out?

Pretty sure you need a refresh() after sending all(0)

If that’s not in awake then… ???

Have you updated all your scripts to most recent versions?

Thanks. Interesting… so you think the refresh call must be made before any other grid updates?

The code in Awake is very similar to this code from norns study 4:

function grid_redraw()
  g:all(0)
  for i=1,16 do
    g:led(i,steps[i],4)
  end
  g:refresh()
end

So there is a call to refresh but not until after some further LED setting is done. On my neotrellis grid at least, the further setting only works for row 1. Very occasionally the other LEDs that are set will flash on briefly.

Inserting an additional call to refresh straight after the all(0) gives better behaviour but again the leds flicker every now and then.

If the issue is with the script rather than my grid then obviously I’ll be relieved!

Well… off the top not my head I’m not really sure. Would need to dig into the code again to remind myself how it works.

If you modified the neotrellis grid code then it is possible something else is happening to cause issues.

What did you change in the code (if anything)?

Edit - it might be useful to doublecheck grid functionality with the grid on your computer and Max with the Monome Home test patch. I’ve not done extensive 8x8 testing and maybe there are bugs?

Thanks again for your help.

I haven’t made any significant changes to the code – just the colours for now – and the behaviour was the same with the precompiled code from your repo.

The monome home patch in Max seems to work just fine; I lost a few minutes gazing at the varibright map test.

Is there some way to log what data is being sent from norns (fates) to the grid over serial?

Not an easy way really. but maybe not the issue here.

Looking at the awake code I think you’re running into something where the script is hard-coded for a 16x8 grid.


function gridredraw()
  local grid_h = g.rows
  g:all(0)
  if edit_ch == 1 or grid_h == 16 then

So - because g.rows is 8 - this next part will never execute.

You’d probably need to dig through this thread for making 8x8 modifications: Norns Scripts for a 64 Grid

I honestly don’t think it’s as simple as Awake needing an 8x8 remix.

The code in Awake does execute because of the or, but in any case – and more significantly – the exact same behaviour arises with the norns-study-4 code which is super simple (and which I did amend for 8 columns), and with the three or four lines I tried in the REPL which I guess are the minimal example to show the issue. Something funny is going on. All the code I’ve looked through seems ok but I’m a long way from seeing the full picture.

Anyway, never mind. If nobody else is seeing issues then it is likely not a problem for other configurations and my little 8x8 use case is very niche. Thanks for taking the time to respond!

on norns/fates, g:led() sets the state of an internal buffer, and does not produce serial traffic.

g:refresh() sends out the buffered state for any 8x8 regions that need refreshing, using the led/map message from the grid serial protocol.

the typical grid size is 8x16, divided into 2 regions (aka quadrants or quads). in the awake script, the loop over column numbers [1, 16] ends up hitting both regions, so on refresh(), two /led/map commands are sent every time.

one thing to check is that the 8x8 device is correctly handling the second /led/map, for the missing quadrant (by ignoring it.) the max script you tested may have been using different commands from the protocol (besides /led/map, there are also commands to set one LED per packet, one column per packet, &c.)

you could try modifying the awake script so it only loops for i=1,8 ...

1 Like

Thanks for that. I infer that norns uses /led/map for every led-setting interaction with the grid, rather than using some of the other commands. Is that right?

Playing around some more I have come up with a shorter sequence of commands that exposes the issue:

g:led(9,8,10)
g:led(1,1,10)
g:led(2,2,10)
g:refresh()

After this, only led 1,1 will light. led 2,2 stays off. The first line is the one that causes the trouble, and only position 9,8 has this effect – I tried everything up to 16,16 and isolated this particular position as the troublemaker.

So, there’s a bug somewhere but I am on its tail!

that’s right. (this could conceivably change in the future.)

how bizarre! yeah i would look for an issue on the LED driver end. maybe consider modifying the firmware on your 8x8 grid to ignore any /led/map with x/y offset greater than 7.

Gonna reset my NT grid to 8x8 right now and do some testing. If you wanna do some back in forth in DM, hit me up.

1 Like

As a followup - yeah this was a bug in my neotrellis grid code. Out of range values for setting leds were not handled correctly, so I think I’ve got that fixed up now. :slight_smile:

1 Like

I was totally wrong about (9,8) being the only problem spot. Not sure how I got so mixed up. Anything x>8 with y in range 1-8 caused problems. The tireless @okyeron found the issue and fixed it.

Hiya,

I have exactly the same problem as you with a 8*8 grid on a Teensy.

Only the First row works randomly. I ran the grid test and the grid is fine.

I was looking into it with @okyeron some time ago, but have left the bug for now.

But yes, im having the same behaviour which makes the grid unusable with Norns/Fates most scripts :frowning: