00:25 | intrac | left the channel | |
00:26 | intrac | joined the channel | |
02:31 | intrac | left the channel | |
02:31 | intrac | joined the channel | |
03:16 | Bertl_oO | off to bed now ... have a good one everyone!
| |
03:16 | Bertl_oO | changed nick to: Bertl_zZ
| |
06:12 | BAndiT1983|away | changed nick to: BAndiT1983
| |
08:49 | anuejn | good morning :)
| |
10:08 | Bertl_zZ | changed nick to: Bertl
| |
10:08 | Bertl | morning folks!
| |
10:17 | se6ast1an | good day
| |
14:00 | Bertl | off for now ... bbftm
| |
14:00 | Bertl | changed nick to: Bertl_oO
| |
15:58 | Bertl_oO | changed nick to: Bertl
| |
16:00 | se6ast1an | MEETING TIME!
| |
16:00 | se6ast1an | who is here?
| 16:03 | Bertl | is here ...
|
16:03 | se6ast1an | just us two it seems
| |
16:04 | Bertl | well, we probably can save the time then ...
| |
16:05 | se6ast1an | true
| |
16:05 | se6ast1an | I will publish the gsoc article then now
| |
16:07 | se6ast1an | https://www.apertus.org/google-summer-of-code-wrap-2020-article-october-2020
| |
16:09 | Bertl | nice
| |
16:10 | se6ast1an | BAndiT1983 you can share some news right?
| |
16:10 | BAndiT1983 | a bit, was not that present lately because of my regular job
| |
16:10 | BAndiT1983 | but this weekend i've finally sat down and experimented with the PCB paneliser
| |
16:11 | BAndiT1983 | we had a problem with rotated data there, which was resulting in complains from the PCB fab
| |
16:11 | BAndiT1983 | after some discussion with Bertl and se6ast1an the solution was found, so the gerber data was rotated by using gerbv command line exporter, then assembled and adjusted in the python scripts
| |
16:12 | BAndiT1983 | final obstacle was the drill layer, but after some experiments with decimal settings it finally worked
| |
16:12 | se6ast1an | beautifully I must say :)
| |
16:12 | se6ast1an | panels have been sent to pcb fabs already for quotes
| |
16:12 | BAndiT1983 | will align with se6ast1an on further tasks, as i'm a bit out of the loop
| |
16:13 | BAndiT1983 | don't have a preview right now, otherwise i would show some nice images of 2d lines ;)
| |
16:13 | BAndiT1983 | maybe visualiser, firmware or bootloader for axiom remote as next
| |
16:13 | BAndiT1983 | that would be it
| |
16:14 | se6ast1an | great, many thanks
| |
16:14 | se6ast1an | now I feel motivated to give a brief insight into the pcb prober as well
| |
16:15 | se6ast1an | to identify the mechanical inaccuracies bertl created a test pattern
| |
16:15 | se6ast1an | https://github.com/apertus-open-source-cinema/pcb-prober/blob/master/calibration/testpattern_v2_150x150.pdf
| |
16:15 | se6ast1an | that I printed and put on the bed of the pcb prober
| |
16:16 | se6ast1an | with the attached microscope camera I then ran an automated optical center detection of around 4000 points and did each measurement 4 times
| |
16:16 | BAndiT1983 | not bad, but i experience the effect where the small dots start to turn gray individually, don't remember the name at the moment
| |
16:16 | se6ast1an | the results were visualized by Bertl
| |
16:16 | se6ast1an | https://github.com/apertus-open-source-cinema/pcb-prober/blob/master/calibration/result%20visualization%2001.svg
| |
16:16 | se6ast1an | https://github.com/apertus-open-source-cinema/pcb-prober/blob/master/calibration/result%20visualization%2002.svg
| |
16:17 | se6ast1an | you can clearly see the errors have a pattern
| |
16:17 | BAndiT1983 | github is crashing there, maybe too big, have to download
| |
16:18 | se6ast1an | yeah lots of lines
| |
16:18 | BAndiT1983 | are the peaks just some random errors?
| |
16:18 | se6ast1an | we suspect its due to the wheels on the ender being slightly egg shapped
| |
16:19 | se6ast1an | possibly because the tension on them is too high or too low
| |
16:19 | Bertl | note that the 'error' is magnified by a factor of 10 (or probably more)
| |
16:19 | BAndiT1983 | usually the belt tension is not that important, at least not to the extent people always think and propagate
| |
16:20 | BAndiT1983 | is the probe head too light and vibrates too much?
| |
16:20 | se6ast1an | I also tweaked the belt tension but what I meant was the pressure on the wheels
| |
16:21 | Bertl | BAndiT1983: for vibration the pattern too much depends on the position
| |
16:21 | se6ast1an | anyway, we figured we wanna try probing now and see where we actually end up
| |
16:21 | BAndiT1983 | ok, strange, haven't looked at the ender construction yet
| |
16:22 | se6ast1an | the probing routine has been added today, there are some things still to be tweaked or improved
| |
16:23 | se6ast1an | at least normal sized pads (0402+) should be hit properly
| |
16:23 | se6ast1an | for the smaller chip pads we will see what the best approach is
| |
16:23 | se6ast1an | maybe optical pad detection, bertl also suggested just trying to probe several points around the target
| |
16:23 | se6ast1an | shotgun approach
| |
16:23 | Bertl | I'm optimistic that we are good for 99% of all pads we have :)
| |
16:23 | se6ast1an | the idea is that the measurement will tell us if we hit immediately
| |
16:24 | BAndiT1983 | optical approach is interesting
| |
16:24 | se6ast1an | the problem is that the movement between centering camera and moving the needle there will also produce an error
| |
16:24 | BAndiT1983 | but what if you hit the pad next to it?
| |
16:24 | se6ast1an | but potentiall smaller error
| |
16:25 | BAndiT1983 | ^it was about "shotgun approach"
| |
16:25 | se6ast1an | yeah, I am curious if the measurement will show that
| |
16:26 | BAndiT1983 | is the other probe on the GND?
| |
16:26 | se6ast1an | I mean if it will allow us to identify the neighbour pad
| |
16:26 | se6ast1an | there is only one probe
| |
16:26 | se6ast1an | but the GND plane is grounded yes
| |
16:26 | BAndiT1983 | ok, am curious how we will recognize individual pads, if it hits the wrong one
| |
16:27 | BAndiT1983 | resistance of the trace?
| |
16:27 | se6ast1an | bertl designed the probe to not just measure connected/not connected but resistance, capacitance, ...
| |
16:27 | se6ast1an | Bertl: can you elaborate
| |
16:28 | Bertl | I think I already did a few months ago ...
| |
16:28 | Bertl | basically we do a resistive as well as capacitive measurement
| |
16:28 | Bertl | this still needs to be fine tuned but for that we need real world measurements which haven't been available yet
| |
16:29 | Bertl | regarding 'hitting the wrong pad', if we are that far off, we have a bigger problem
| |
16:29 | BAndiT1983 | i remember something like that, but had already quite many other things in-between, so it got lost somewhere in the abyss of the mind
| |
16:30 | Bertl | chances are, if we miss a pad, we a right on the edge of the pad
| |
16:30 | Bertl | this means that e.g. a circular motion around this point will either hit the pad or miss it as well
| |
16:30 | Bertl | (a sufficiently small circular motion that is :)
| |
16:31 | Bertl | so the question there becomes: can we tell whether we did hit a pad or not?
| |
16:31 | Bertl | and I'm somewhat confident that we can tell the difference there
| |
16:31 | BAndiT1983 | just a theoretical question, as i wasn'T aware of wheels on the ender (my prusa doesn't have such stuff), would it work better with "belt only" printer base?
| |
16:32 | Bertl | for sure a more stable construction would work better, we just started with the ender 2 because it was available and cheap
| |
16:32 | se6ast1an | the ender 3 has a linear rail modification kit
| |
16:32 | se6ast1an | not too expensive
| |
16:33 | se6ast1an | but means we need to build a new unit from scratch
| |
16:33 | Bertl | so for now, let's see how well this one does ...
| |
16:33 | se6ast1an | exactly
| |
16:34 | se6ast1an | so much for the prober
| |
16:34 | se6ast1an | Bertl: do you have any news to share?
| |
16:35 | Bertl | guess so ...
| |
16:35 | Bertl | besides helping out with the prober and other stuff, I worked a little more on the cmv_snap* side
| |
16:36 | Bertl | and I did a SIMD (NEON) implementation for the line conversion
| |
16:36 | Bertl | this can now pull the image data from memory in about 140ms
| |
16:37 | Bertl | still if we run the cmv_snap over ssh, we get about 1.6-1.8 seconds
| |
16:38 | Bertl | but for local storage this has some advantages and if we find a clever way to eliminate the ssh overhead, we can easily transfer images in less than 500ms
| |
16:38 | se6ast1an | did you also benchmark writing to micro sd card ?
| |
16:38 | se6ast1an | ah, great
| |
16:38 | BAndiT1983 | iss SSH mandatory or can we use (R)UDP?
| |
16:39 | Bertl | we can use whatever we like I guess?
| |
16:40 | Bertl | I also updated the storage system at the hub, added two disk drives there and we are currently spreading the data over the drives
| |
16:41 | Bertl | and I manually probed the new power board PCBs so that we can start assembly for testing
| |
16:41 | se6ast1an | two boards actually no?
| |
16:41 | Bertl | two boards were tested, yes, the third one is in your prober :)
| |
16:42 | se6ast1an | correct
| |
16:42 | se6ast1an | regarding snap
| |
16:42 | se6ast1an | could you test this script with it:
| |
16:42 | se6ast1an | https://github.com/apertus-open-source-cinema/axiom-firmware/blob/master/software/scripts/axiom_picture_snap.sh
| |
16:42 | se6ast1an | until line 21
| |
16:42 | se6ast1an | line 15 & 16 are a work around because snap hung with every econd run
| |
16:42 | se6ast1an | *second
| |
16:43 | Bertl | so what you want tested is a snap to SD card, right?
| |
16:43 | se6ast1an | yes
| |
16:43 | se6ast1an | the script doesnt do much
| |
16:43 | se6ast1an | disable hdmi
| |
16:43 | Bertl | i.e. we do not need the other stuff there
| |
16:44 | BAndiT1983 | regarding UDP or whatever can be used, can't we just check wit socat if it will work? just as a proof of concept -> https://knplabs.com/en/blog/share-files-on-the-local-network-with-socat
| |
16:44 | se6ast1an | capture image to sd card with unique name derived from current date
| |
16:44 | se6ast1an | turn hdmi back on
| |
16:44 | se6ast1an | the rest is dng conversion, and raw development that doesnt matter for the test
| |
16:44 | Bertl | the problem I see here is that there is no sync
| |
16:44 | Bertl | so most of the SD writes will end up in cache instead
| |
16:45 | se6ast1an | good idea, added
| |
16:45 | Bertl | but I can design a test which actually writes to SD directly
| |
16:45 | Bertl | (because caching and then sync is a baad idea too :)
| |
16:45 | se6ast1an | do your magic :)
| |
16:45 | se6ast1an | and update the script then please
| |
16:46 | Bertl | I plan to spend some more time with the memory read/reorder/write anyway, so no problem there
| |
16:47 | se6ast1an | great
| |
16:47 | se6ast1an | vup messaged me: no news
| |
16:47 | se6ast1an | anuejn is currently occupied with a lot of other things
| |
16:47 | se6ast1an | he will let us know when his life has more structure again
| |
16:49 | bluez_[m]1 | Hey guys! I can share something...
| |
16:49 | se6ast1an | great, please do!
| |
16:50 | bluez_[m]1 | tx!.. so I tested my driver with the latest kernel in-tree (had some help from vup there), and it seems to work nicely
| |
16:50 | Bertl | yay!
| |
16:51 | bluez_[m]1 | only I realized as soon as the driver is bound with the devicetree and probes...it automatically does some jtag stuff (queries status)
| |
16:51 | bluez_[m]1 | so it screws up the state as the jtag is not turned on by then (which is done by a script now)
| |
16:52 | bluez_[m]1 | reloading the driver works fine then
| |
16:52 | Bertl | so we should focus on that and fix this with a little help from the pic side
| |
16:52 | bluez_[m]1 | but i think it would be better if we turn jtag on from within the driver...
| |
16:52 | bluez_[m]1 | https://drive.google.com/file/d/109YyFnUghoU8Ajr8Et2xjYYEmsQQNuwB/view?usp=sharing
| |
16:53 | bluez_[m]1 | Bertl: yep... have a look at this patch.. looks good?
| |
16:54 | Bertl | well, kind of ... let's discuss this in the next few days, I should have some time
| |
16:55 | bluez_[m]1 | other than this... i have yet to add some kernel documentation, update the newer devm version of some functions, and some other clean up stuff... I guess it will be somewhat ready for mainline then...!
| |
16:55 | bluez_[m]1 | Bertl: ah, alright alright
| |
16:56 | bluez_[m]1 | we can make this a more generic command rather than just for jtag as you mentioned...
| |
16:56 | Bertl | yes, that's what we should aim at
| |
16:56 | bluez_[m]1 | anyway... i guess thats it from me now..
| |
16:56 | Bertl | like a command register to do 'stuff'
| |
16:57 | bluez_[m]1 | Bertl: yeah yeah.. we can have a switch inside that function basically that does different stuff based on the argument..
| |
16:58 | bluez_[m]1 | but yea we should discuss that as you are familiar with what other 'stuff' we can include here..
| |
17:06 | se6ast1an | ok, anyone else here otherwise we can conclude this weeks meeting
| |
17:09 | se6ast1an | MEETING CONCLUDED
| |
17:09 | se6ast1an | many thanks everyone!
| |
19:34 | comradekingu | left the channel | |
19:36 | comradekingu | joined the channel | |
19:54 | Bertl | off to bed now ... have a good one everyone!
| |
19:54 | Bertl | changed nick to: Bertl_zZ
| |
20:15 | RexOrCine | joined the channel | |
20:18 | aombk2 | joined the channel | |
20:25 | matthew[m]3 | left the channel | |
20:25 | aombk | left the channel | |
20:28 | matthew[m]3 | joined the channel | |
21:41 | BAndiT1983 | changed nick to: BAndiT1983|away
| |
22:27 | lexano | left the channel | |
22:52 | lexano | joined the channel |