#linuxcnc Logs

Feb 18 2024

01:26 AM fdarling: pcw-home: I am still struggling with PacketUART reception (:-|
04:06 AM fdarling: pcw-home: okay, I might have figured it out... I have some questions though: what type of error handling do I "need" to do to keep the PacketUART RX continuing to run properly? Like do I need to clear some sticky bits if they show up? Do I need to reset it under some circumstances? I was hoping I'd only have to reset it when my own watchdog bit from no responses for too long of a period...
04:06 AM fdarling: (I ask because the mesa-modbus driver seems to be very reset happy)
04:42 AM Tom_L: morning
04:44 AM fdarling: andypugh_: I think I may have found a bug in pktuart.c... https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/drivers/mesa-hostmot2/pktuart.c#L537-L539
04:46 AM fdarling: it seems that it's trying to check the tx mode/status register for a flag, but that doesn't work since it's a queued read not a blocking immediate read (like it used to be?) I think this is a vestige of the old "extra packet" blocking code, and instead it just gives false nuisance errors if you are sending a size that happens to have the bit 0x10 set (sixteen). You are allowed to transmit up to 16 32-bit words or 64 bytes
04:52 AM fdarling: This is the old version of the code that I think it came from: https://github.com/LinuxCNC/linuxcnc/blob/bab0790f269c7b26eea80737b15cba7bdce50a5d/src/hal/drivers/mesa-hostmot2/pktuart.c#L326-L332
04:56 AM JT-Cave: morning
04:58 AM fdarling: pcw-home: I see that the PacketUART frame size FIFO is 16 deep, but what about the transmit data FIFO? Is it also 16x 32-bit words? Or something larger?
04:59 AM andypugh_: fdarling: Can you raise a bug report on github so that we can talk through it with PCW?
04:59 AM fdarling: andypugh_: yes I can, I just wanted another pair of eyes on it before I jumped the gun on a bug report
05:00 AM JT-Cave: steam bending white oak https://www.youtube.com/watch?v=ANT51wUMqvg
05:04 AM andypugh_: Does the strap chill the wood? Would it help to pre-heat it?
05:05 AM JT-Cave: the strap provides compression for the bend
05:05 AM JT-Cave: if the outside radius expands it will split
05:05 AM andypugh_: Yes, I know that is what it is for. But would it help if it was also warmed?
05:05 AM JT-Cave: I don't think it would matter as the strap is only 0.007" thick
05:06 AM JT-Cave: so it would not retain heat for long
05:08 AM JT-Cave: that was the 6th attempt at steam bending... improving tools and technique each time
05:10 AM JT-Cave: I'm really surprised to see I have 315 subscribers... used to be only a few
06:29 AM Getty4 is now known as Getty
07:30 AM JT-Cave: Tom_L, https://github.com/jethornton/flexgui/blob/master/flexgui/src/libflexgui/status.py
07:30 AM JT-Cave: https://github.com/jethornton/flexgui/blob/master/flexgui/src/libflexgui/startup.py#L28
08:55 AM Tom_L: JT-Cave, i don't follow quite what's happening but it looks better than what i had
08:58 AM Tom_L: i can only compare it to what i already know
08:59 AM Tom_L: we have a command 'aeval()' that executes a code block on an array 'list' or dbeval() a data file and this looks somewhat similar
09:00 AM Tom_L: you have a full list and if it finds the name in the list, it gets updated
09:00 AM Tom_L: instead of a for..next we would use aeval there
09:00 AM Tom_L: only python doesn't use 'next' there
09:00 AM JT-Cave: I'll add some comments after break fast
09:01 AM Tom_L: so that connects the widget right?
09:01 AM JT-Cave: python doesn't have arrays or those commands
09:01 AM JT-Cave: that?
09:01 AM Tom_L: the parent.status_labels[item] = f'{item}'
09:02 AM JT-Cave: that line assigns a value to a key in the dictionary
09:02 AM Tom_L: from hal?
09:02 AM JT-Cave: parent.status_labels[item] = f'{item}_lb'
09:03 AM Tom_L: yeah i forgot the _lb
09:03 AM JT-Cave: the _lb is added on the item
09:03 AM Tom_L: it adds the suffix but it doesn't connect hal at that point?
09:03 AM JT-Cave: so it creates for example 'current_line': 'current_line_lb' in the dictionary
09:04 AM JT-Cave: key: value
09:04 AM JT-Cave: break fast time here
09:06 AM pcw-home: fdarling: 16 is the maximum number of pending frames all stored in the data FIFO (typically 1024 bytes)
09:11 AM pcw-home: (so maximum frame size would be 1024 bytes if a single packet is sent/received which is the case for synchronous comms like MODBUS)
09:33 AM JT-Cave: Tom_L, take a look at startup.py and status.py now, I've added some comments
09:38 AM Tom_L: so you use the list to create a dict of active widgets
09:39 AM Tom_L: then dict will have the state of each one later on
09:40 AM Tom_L: [acceleration_lb][xxx]
09:42 AM Tom_L: var = parent.status.[acceleration_lb][xxx]
09:42 AM Tom_L: or something similar
09:43 AM Tom_L: what is actions.py for?
09:45 AM NoSpark: Morning all
09:46 AM NoSpark: Is it ok to ask about non linuxcnc specific stuff in here?
09:46 AM Tom_L: why not?
09:47 AM NoSpark: I'm trying to figure out the best way to put a together a high temperature build chamber for a 3d printer
09:47 AM pcw-home: fdarling: That code looks fine (bit 4 on the Packet UART mode register is SCFIFO error which gets set if you to push more than 16 frames)
09:47 AM NoSpark: by high temp, I'm thinking about 250DegC
09:47 AM pcw-home: if you _try_ to
09:48 AM JT-Cave: for example the dictionary of labels and status that are found is only created once
09:48 AM NoSpark: pcw-home: Your mesa stuff is excellent, but it is still a chore to compile custom bitfiles :S
09:48 AM Tom_L: NoSpark, for a reflow oven i used home insulation to keep the temp more constant
09:48 AM JT-Cave: that dictionary is used to update the status labels
09:49 AM Tom_L: in status.py
09:49 AM JT-Cave: a menu item creates an action so all menu items are handled in actions.py
09:49 AM NoSpark: Tom_L: I'm more thinking about how to keep everything OUT of the chamber. ball nuts, guide block etc wont like that much heat
09:50 AM JT-Cave: the dictionary only has the label name and status name not the state of the status item
09:50 AM pcw-home: NoSpark: If you have the tools, its not too bad (just edit one pinout file and include it in the top level source and re-compile)
09:51 AM NoSpark: pcw-home: Getting the tools took 2 days for me, trying to get a licence working for ise. I ended up purging my AMD account, and creating a new one before I could get it to work.
09:53 AM NoSpark: (and forgetting to reset the device after a flash took an embarisinly long time to figure out too )
09:54 AM NoSpark: Tom_L supplied a awsome how to as well, shouuld prolly be on your website :)
09:54 AM pcw-home: I have never had much trouble with the webpack license, but have not changed it recently
09:54 AM Tom_L: put it in the wiki
09:55 AM Tom_L: mine is there also
09:56 AM JT-Cave: the axis and joint dictionary's have to be accessed a bit different because they are a dictionary of dictionaries
09:56 AM JT-Cave: so stat.axis[0]['velocity']
09:58 AM NoSpark: pcw-home: also, while you are here, are all the pins usually assigned to the 5i52 serial ports bidirection? for example, I could use the RX pins to generate a PWM output? I have the bitfile done now, just hadn't had time to test yet?
09:59 AM Tom_L: yeah i found that out myself
09:59 AM pcw-home: 5I52?
09:59 AM Tom_L: would the others be considered tuples instead of dictionaries?
09:59 AM NoSpark: sorry, 7i52
10:00 AM NoSpark: has 6 422 serials and 6 encoder inputs
10:02 AM pcw-home: The TX's can be used for any output, the RX's for any differential input
10:02 AM NoSpark: so a PWM on the output is fine, but I can't use the RX pin for another PWM out?
10:04 AM pcw-home: no, because there is a differential receiver driving the RX FPGA pins
10:04 AM NoSpark: understood, figured as much
10:05 AM NoSpark: and finally, is pkt_uart compatible with RS485 on ports that support 485? (ports 0 and 3 IIRC) ?
10:06 AM JT-Cave: hmm they could be tuples
10:10 AM JT-Cave: type(s.axis[0])
10:10 AM JT-Cave: <class 'dict'>
10:11 AM pcw-home: Yes, the pktuart is designed for RS-422 and RS-485 applications
10:13 AM NoSpark: pcw-home: perfect :) Thank u
10:17 AM pcw-home: mesa-modbus does work but still has some bugs
10:18 AM JT-Cave: Tom_L, axis and joint are tuple of dictionaries
10:21 AM pcw-home: (mesa-modbus uses RS-485)
10:23 AM chris1313: hey all looking for some help on getting isolcpsus to work on debian and linux 2.9
10:31 AM NoSpark: what do you need?
10:31 AM NoSpark: chris1313: ?
10:32 AM NoSpark: GRUB_CMDLINE_LINUX_DEFAULT="mitigations=off idle=poll rcu_nocb_poll rcu_nocbs=3 nohz=on nohz_full=3 kthread_cpus=0,1,2 irqaffinity=0,1,3 isolcpus=nohz,managed_irq,domain,3 lapic=notscdeadline hpet=disable i915.i915_enable_rc6=0 i915.powersave=0 intel_idle.max_cstate=1 splash quiet"
10:35 AM chris1313: Should i be trying to modify that in a Grub.d folder
10:35 AM chris1313: ?
10:35 AM NoSpark: what os?
10:35 AM chris1313: debian 12
10:35 AM NoSpark: /etc/default/grub
10:36 AM NoSpark: for the moment, I would suggest just changing the line to:
10:37 AM NoSpark: GRUB_CMDLINE_LINUX_DEFAULT="mitigations=off idle=poll rcu_nocb_poll rcu_nocbs=3 nohz=on nohz_full=3 irqaffinity=0,1,3 isolcpus=nohz,managed_irq,domain,3"
10:37 AM NoSpark: if you have a quad core
10:37 AM chris1313: ok. located the file. next looking for GRUB_CMDLINE...
10:38 AM chris1313: Yes i have a i5 quad core
10:38 AM chris1313: so cpu should be 3 correct
10:38 AM NoSpark: leave grub_cmdline alone
10:38 AM chris1313: do i just add the text above then?
10:39 AM NoSpark: just comment out the existing GRUB_CMDLINE_LINUX_DEFAULT line, and then add the entire line as above
10:39 AM Roguish: you might have to experiment a bit to find the best configuration
10:39 AM chris1313: understood. modifing now
10:40 AM NoSpark: once you have modified the line, don't forget to run ->> sudo update-grub
10:40 AM NoSpark: Roguish: youre correct, but that line is pretty generic
10:42 AM NoSpark: chris1313: because quiet and splash have been left off, your boot process will be quite noisy. after a couple of successful boots, you can add quiet and splash back
10:42 AM chris1313: No spark sorry dumb question here but i just tried to update it and save and it gave me this error " error opening file "/etc/defaul/grub" permission denied. the file on disk may now be trunkated.
10:42 AM NoSpark: hrmmm
10:43 AM chris1313: do i need to open the file instead using sudo mouse pad from terminal?
10:43 AM chris1313: im really new to this so just asking
10:43 AM NoSpark: can you run this command ->> cat /etc/boot/grub | nc termbin.com 9999
10:44 AM NoSpark: that will post your grub config file, and if you paste the address it spits out, we can check it
10:44 AM NoSpark: wait, I made a mistake
10:44 AM NoSpark: cat /etc/default/grub | nc termbin.com 9999
10:45 AM chris1313: i got a bash:nc: command not found
10:45 AM NoSpark: oh
10:45 AM chris1313: when i entered the cat /etc/default/grub | nc termbin.com 9999
10:45 AM NoSpark: debian doesn't have netcat anymore? geez, on sec
10:46 AM NoSpark: can install netcat first by running ->> sudo apt install netcat-traditional
10:46 AM chris1313: ok i will try that
10:46 AM NoSpark: I assume your linuxcnc computer is connected to the net?
10:47 AM chris1313: yea im on it now.
10:47 AM chris1313: just got this back
10:47 AM NoSpark: btw, don't feel like your asking stupid questions. Its fine, and your doing great. everyone has to start somewhere :)
10:47 AM chris1313: Reading package lists... Done
10:47 AM chris1313: Building dependency tree... Done
10:47 AM chris1313: Reading state information... Done
10:47 AM chris1313: E: Unable to locate package netcat-traditional
10:47 AM NoSpark: ok, run ->>> sudo apt update first
10:47 AM roycroft: sudo apt update
10:47 AM chris1313: linux is so confusing. i appreciate all the help
10:48 AM NoSpark: Sudo apt update will tell apt to go online and download a list of all the available programs
10:48 AM NoSpark: on windows (before store), you are expected to go and find random programs on disks or the internet, download them, install them, and then remember to keep them updated
10:50 AM NoSpark: on debian systems, apt handles all that. if you want a program to edit photos, just type >> apt search photo editor << and it will list all the photo editors available for immediate install
10:51 AM chris1313: NoSpark im going to copy what is it coming back with because i have not tried to update. is that ok?
10:51 AM NoSpark: you would then pick one from the list, and type >> sudo apt install gimp << for example to install it. if any bugs are found in gimp later, apt will download an update for you
10:51 AM NoSpark: pm me?
10:51 AM chris1313: ok
10:51 AM NoSpark: try not to flood public channels
10:53 AM chris1313: understood
10:53 AM NoSpark: apt is complaining that the USB key or CD you used to install debian is missing.
10:54 AM NoSpark: It doesn't need it, just wants it so if you are installing something common, it doesn't have to download it from the net
10:54 AM chris1313: i installed of a usb key. i just plugged it back in
10:54 AM NoSpark: run >> sudo apt update << again and it should complain less
10:56 AM chris1313: NoSpark i re ran sudo update and PM the result back to you
10:57 AM chris1313: still mentioned the CD rom even though i used usb and installed based on the tutorial on the linuxcnc website.
10:58 AM NoSpark: okay, its a really easy fix, but we can just ignore it, up to you, I don't mind telling you how to fix it
10:58 AM chris1313: please share i would like to learn incase i ever have to reinstall
10:58 AM chris1313: im trying to write all this down.lol
10:59 AM NoSpark: you should be able to install netcat now
10:59 AM NoSpark: try running >> sudo apt install netcat-traditional << and see what happens
11:00 AM chris1313: it build and reads but results in"E: Unable to locate package netcat-traditional"?
11:01 AM NoSpark: also, rather than retyping everything, try pressing up on your keyboard
11:01 AM NoSpark: ok, I'll talk on pm, cause this is pretty simple linux stuff, and doesn't really belone here
11:01 AM chris1313: ok thanks.
11:20 AM Tom_L: serpentine belt changed
11:27 AM flyback: chris1313, i THINK YOU Can fix that in /etc/apt something
11:27 AM flyback: like a config file
11:39 AM * JT-Cave hears a nap calling his name
11:39 AM JT-Cave: Tom_L, got axis stat figured out...
11:40 AM NoSpark: who is responcible for the default linuxcnc isos?
11:45 AM JT-Cave: no one, it's all volunteer work
11:46 AM JT-Cave: if you're asking about the buildbot that's Seb's creation
11:46 AM JT-Cave: now it's really nap time
11:47 AM Tom_L: nearly
11:47 AM Tom_L: belt changed, cleaned up, nap
11:47 AM Tom_L: are you doing axis or joint?
11:48 AM Tom_L: there's only a handfull of axis entries iirc
11:50 AM Tom_L: i think andy makes the iso files, seb does debs
11:50 AM Tom_L: i think
11:50 AM Roguish: ditto
11:50 AM Tom_L: http://buildbot2.highlab.com/debian/dists/bookworm/2.9-uspace/binary-amd64/
11:51 AM Tom_L: seb's new buildbot2 site
11:51 AM lcnc-relay: <staasiu> sorry if I interrupt, idk what the relay bot is doing
11:51 AM lcnc-relay: <staasiu> but I just wanted to ask if anyone here is working in qtplasmac and would know why the cone/tool doesn't show up in my preview?
11:54 AM Tom_L: http://linuxcnc.org/docs/stable/html/plasma/qtplasmac.html
11:54 AM Tom_L: search 'cone size'
11:54 AM Tom_L: beyond that, no clue
11:59 AM lcnc-relay: <satiowadahc#0> What tool are you using? It does read the cone size from the tool table
11:59 AM Tom_L: enter a diameter in the tool table
12:00 PM lcnc-relay: <satiowadahc#0> And forward angle*
12:01 PM lcnc-relay: <satiowadahc#0> https://github.com/LinuxCNC/linuxcnc/blob/af13d6e6e7c689d47b4016815f3df4b2e410e12b/lib/python/rs274/glcanon.py#L1365
12:02 PM lcnc-relay: <satiowadahc#0> Apparently there is also magic comments that can change it
12:10 PM lcnc-relay: <staasiu> I'm really new to this, idk what to with those 😔
12:10 PM lcnc-relay: <staasiu> plasma torch #0
12:12 PM lcnc-relay: <staasiu> been looking through that site many times, nothing helpful. that's why I joined here 😅
12:13 PM lcnc-relay: <satiowadahc#0> Or ini file rather.
12:13 PM lcnc-relay: <satiowadahc#0>
12:13 PM lcnc-relay: <satiowadahc#0> https://github.com/LinuxCNC/linuxcnc/blob/af13d6e6e7c689d47b4016815f3df4b2e410e12b/lib/python/rs274/glcanon.py#L517
12:13 PM lcnc-relay: <satiowadahc#0>
12:13 PM lcnc-relay: <satiowadahc#0> Set CONE_BASESIZE=<NUMBER> in the display section of your ini file
12:14 PM lcnc-relay: <staasiu> tried that already :(
12:20 PM lcnc-relay: <satiowadahc#0> What's your tool table look like? Should be a file that ends in .tbl
12:21 PM lcnc-relay: <satiowadahc#0> ... does it actually matter what the extension is...? Theoretically it could be any text file... imma gonna have to look into that...
12:30 PM lcnc-relay: <skunkworks8841> https://jauriarts.org/_matrix/media/v1/download/jauriarts.org/YEBShzYBXiZvJnSqEytAMnJD
12:31 PM lcnc-relay: <skunkworks8841> Well . Restoring the clonezilla image 'just worked'
12:32 PM lcnc-relay: <skunkworks8841> Crazy
12:43 PM lcnc-relay: <roguish> 4 monitors is kinda crazy
12:44 PM lcnc-relay: <roguish> lots of realestate
12:44 PM lcnc-relay: <roguish> my twin 32"ers are nice too
12:48 PM roycroft: in my office my main computer is a 27" imac that is flanked by a 4k 27" display on either side
12:48 PM roycroft: it's on a corner desk, so the side displays are angled in
12:48 PM roycroft: to the far left is an old 20" imac running linux mint
12:49 PM roycroft: i had originally intended to add a 4th display to the imac, above the primary one, but the 3 display setup has worked very nicely for me
12:50 PM JT-Cave: Tom_L, I'm having all the status items available for the user
12:52 PM lcnc-relay: <roguish> JT: status is a good thing....
12:52 PM lcnc-relay: <roguish> how about halshow ?
12:52 PM lcnc-relay: <roguish> a button to start it
01:08 PM JT-Cave: https://github.com/jethornton/flexgui/blob/master/flexgui/src/libflexgui/actions.py
01:08 PM lcnc-relay: <staasiu> https://jauriarts.org/_matrix/media/v1/download/jauriarts.org/LXUTXoMsPOjOhmFHajaIyEom
01:18 PM Tom_L: JT-Cave, don't see how you make the connections to things like halshow there
01:19 PM JT-Shop: I've not made any connections to actions just have the function defined so it will not error out
01:19 PM lcnc-relay: <skunkworks8841> The 2 bottom monitors are onboard video for the Debian host.. top 2 are the windows vm.. it's own video card running passthrough
01:19 PM JT-Shop: https://github.com/jethornton/jet/blob/master/jet/src/libjet/menus.py#L56
01:20 PM JT-Shop: for example the hal show one ^^
01:33 PM Tom_L: can you pass parameters to those outside programs?
01:33 PM JT-Shop: yes
01:33 PM Tom_L: halshow with this config for example
01:34 PM Tom_L: halshow : last config used
01:35 PM JT-Shop: halshow doesn't take any parameters
01:35 PM Tom_L: i noticed now that axis opens the last used one
01:35 PM JT-Shop: it just shows all the hal pins, parameters and signeals
01:36 PM JT-Shop: ah yes it opens the last show somehow
01:36 PM Tom_L: that's handy
01:36 PM JT-Shop: remind me again after I get flex up and running
01:43 PM JT-Shop: right now I'm just trying to get the framework done
01:55 PM JT-Shop: halshow uses a pref file in the users home directory so it's not something you can configure
01:56 PM Roguish: just a button somewhere to start it up. axis has it. so does qtdragon.
01:57 PM JT-Shop: you add menu items and by magic they work
01:57 PM mrec: does anyone have the JMC JAND Modbus-RTU protocol specification in english? I only have it in chinese so far and it takes time to translate all the registers
01:58 PM Centurion_Dan1 is now known as Centurion_Dan
01:58 PM JT-Shop: https://github.com/jethornton/flexgui/blob/master/flexgui/src/libflexgui/actions.py
01:58 PM JT-Shop: Roguish, ^^^^^^^
01:58 PM lcnc-relay: <roguish> well, ok. so, is Flexgui just a new incarnation of Jet ???
02:00 PM JT-Woodshop: well yes using all the knowledge I learned coding jet
02:00 PM JT-Woodshop: also improving the code a lot
02:00 PM lcnc-relay: <roguish> cool
02:00 PM JT-Woodshop: in the mean time I'm using jet on my BP
02:03 PM -!- #linuxcnc mode set to +v by ChanServ
02:04 PM Tom_dev: subprocess.Popen(['halshow', "estop.halshow"])
02:06 PM JT-Woodshop: what does that do?
02:07 PM Tom_L: starts halshow with estop.halshow as a parameter
02:07 PM Tom_L: just one i had on hand
02:07 PM JT-Woodshop: what is estop.halshow?
02:07 PM Tom_L: a saved halshow file
02:07 PM Tom_L: probably in the config directory
02:07 PM Tom_L: i put it in the jet source for now
02:07 PM JT-Woodshop: ah ok, that's something you have to save first?
02:08 PM Tom_L: yes
02:08 PM JT-Woodshop: the automatic save goes in the home dir
02:08 PM Tom_L: axis saves the last one automatically
02:08 PM Tom_L: i was running the test with ./jet though
02:09 PM Tom_L: not the home directory
02:09 PM JT-Woodshop: axis saves what?
02:10 PM Tom_L: axis saves the last halshow session but i don't know where yet
02:11 PM Tom_L: so if you just run halshow, it comes up with the last config used
02:11 PM Tom_L: for the halshow watch window
02:12 PM JT-Woodshop: axis doesn't save halshow, halshow saves it to the home dir
02:12 PM JT-Woodshop: .halshow_preferences
02:12 PM Tom_L: well when it's run from axis machine menu was what i meant
02:13 PM JT-Woodshop: you can run halshow from a terminal and it still loads the last saved pref file
02:13 PM JT-Woodshop: which is in the home directory
02:14 PM lcnc-relay: <schoch_> I've been playing with encoders and verilog, anyone here doing any FPGA stuff?
02:15 PM Tom_dev: not recent enough to help
02:15 PM Roguish: the halshow file is saved in the .ini directory, halshow.preferences unless you save it specifically
02:15 PM lcnc-relay: <schoch_> it seems to me that calculating encoder velocity maybe is better suited to be done in linuxcnc and not the fpga
02:16 PM Roguish: there is halshow, calibration, hal meter, and hal scope....
02:16 PM lcnc-relay: <schoch_> the one thing that perhaps is useful is to send a counter value between index pulses, but that also seems easily done in a hal module
02:16 PM Tom_L: https://www.youtube.com/watch?v=o8lezpJhfAo
02:17 PM lcnc-relay: <schoch_> that is just some stranger fiddling his knob
02:18 PM Tom_L: no stranger to me
02:18 PM Roguish: they can all be started via the .ini file with [applications] section
02:18 PM lcnc-relay: <schoch_> i hooked up a heidenhain uAss encoder, it is 12800 PPR without doing any sin/cos interpolation.
02:18 PM Roguish: but a simple button to start each one would be really handy
02:18 PM JT-Shop: looks like halshow saves a pref file in what ever dir it's ran from
02:19 PM lcnc-relay: <schoch_> i made some transimpedance amplifiers to convert the sin/cos to square waves.
02:19 PM JT-Shop: Roguish, https://github.com/jethornton/flexgui/blob/master/flexgui/src/libflexgui/actions.py
02:19 PM lcnc-relay: <schoch_> i was thinking it would be fun (aka nightmarishly complicated) to try to do the interpolation in the FPGA
02:19 PM JT-Shop: https://github.com/jethornton/flexgui/blob/master/flexgui/src/libflexgui/startup.py#L20
02:19 PM JT-Shop: Roguish, ^^^^^^
02:20 PM Roguish: JT-Shop, you're the man.....
02:20 PM lcnc-relay: <schoch_> xxcodery does a flexgui/jet channel make sense. this chan is getting quite a lot of that sort of traffic
02:21 PM Tom_dev: it's all linuxcnc related
02:21 PM Roguish: hey, you got a .deb
02:21 PM Roguish: i'll try it
02:21 PM XXCoder: yeah its fine to talk about flexgui/jet in here
02:21 PM Tom_dev: better than politics or .....
02:21 PM JT-Shop: Roguish, I'm still working on the framework for flex so not functional at this point
02:22 PM lcnc-relay: <schoch_> any source you can point me to?
02:22 PM JT-Shop: schoch_ jet and flex are linuxcnc guis
02:22 PM Roguish: JT-Shop, i realize that.. no problem.
02:22 PM JT-Shop: https://github.com/jethornton
02:22 PM lcnc-relay: <schoch_> i understand that, but so is qtpyvpc and that has it's own channel
02:23 PM Tom_dev: it's not currently being developed is it?
02:23 PM XXCoder: it was heavily discussed for quite a while, been quiet for a while though
02:23 PM lcnc-relay: <schoch_> there is also a development channel
02:23 PM JT-Shop: I think it's being maintained but the orig chap has not been seen for a few years
02:23 PM lcnc-relay: <schoch_> no one seems to use that though
02:23 PM Tom_dev: probebasic was discussed here quite a bit for quite a while
02:25 PM JT-Shop: time to talk about chickens now
02:25 PM Tom_dev: we might even discuss the soup of the day
02:28 PM Tom_L: we do however try to answer all linuxcnc questions if at all possible
02:29 PM JT-Cave: yup
02:30 PM Roguish: JT-Cave, hey, how should i intall and try flex? the .deb file?
02:30 PM Tom_L: nothing to run yet
02:30 PM JT-Cave: I wouldn't try it yet
02:30 PM Roguish: doh.
02:31 PM Roguish: ok
02:31 PM Tom_L: it's like a build a bear
02:31 PM Tom_L: drop widgets and the code comes with them
02:32 PM pcw-home: schoch: velocity estimation (for quadrature encoders) _is_ done by LinuxCNC
02:35 PM lcnc-relay: <schoch_> pcw-home, so the mesa boards don't even send z pulse timer counts?
02:36 PM lcnc-relay: <schoch_> i wrote a hal component to do it a few weeks ago
02:38 PM lcnc-relay: <schoch_> 10 iron
02:38 PM lcnc-relay: <schoch_> never heard of that before
02:42 PM pcw-home: Mesa quadrature encoder modules report counts and count timestamps, allowing velocity estimation
02:43 PM pcw-home: This is typically 5 to 10x better than just counts/delta_time (and much better at low speeds)
02:44 PM Tom_L: linux just reported keyboard battery low 10%.. i don't have a wireless kbd
02:44 PM pcw-home: the actual velocity estimation is done in LinuxCNC (in the driver) as its quite fussy with a lot of edge conditions
02:46 PM pcw-home: LinuxCNCs encoder comp does basically the same thing but uses the base thread for timing between edges
02:48 PM lcnc-relay: <schoch_> i used the encoder comp as a starting point for my module
02:48 PM lcnc-relay: <big_kevin420> hook me up when your done
02:48 PM lcnc-relay: <big_kevin420> remora has some messy velocity calculations
02:49 PM lcnc-relay: <schoch_> pcw-home do you know what timebase mesa uses, is it the sys_clk?
02:50 PM Tom_L: BASE_PERIOD = 50000 - the Base task period in nanoseconds.
02:50 PM Tom_L: http://linuxcnc.org/docs/stable/html/config/ini-config.html#sub:ini:sec:emcmot
02:50 PM pcw-home: Mesa cards have multiple timebases (For Ethernet cards typically just 100 MHz and 200 Mhz)
02:51 PM Tom_L: ^^ for a normal comp
02:52 PM pcw-home: 100 MHz from most modules, 200 MHz for PWM and things like BISS that do wire length skew adjustments
03:00 PM lcnc-relay: <schoch_> pcw-home, thanks! helpful info
03:00 PM lcnc-relay: <schoch_> seems like 200Mhz timestamp isn't really needed for velocity estimation though
03:00 PM lcnc-relay: <schoch_> or 100, or even 1Mhz
03:00 PM lcnc-relay: <schoch_> well maybe 1Mhz for pulses
03:01 PM lcnc-relay: <schoch_> but Z index shouldn't go much higher than 20k*60 right?
03:01 PM lcnc-relay: <schoch_> er 20k/60
03:02 PM lcnc-relay: <schoch_> hmm, so my heidenhain should make 4.275Mhz pulses @20k rpm (which i don't think it can do)
03:02 PM pcw-home: For the encoder timestamp you have a choice of 1 MHz or 10 MHz
03:03 PM lcnc-relay: <schoch_> but that is only 334 z pulses per second
03:03 PM lcnc-relay: <schoch_> should say index rather than z, maybe confusing in cnc context
03:04 PM pcw-home: Typically the analog photodiode signal conditioning circuitry limits you to much lower frequencies
03:05 PM lcnc-relay: <schoch_> ya, i doubt my home made circuit is up to Mhz speeds
03:05 PM lcnc-relay: <schoch_> i guess i could calculate what it can do
03:06 PM lcnc-relay: <schoch_> i should look for a interpolator on ebay to see how accurate that thing is
03:08 PM lcnc-relay: <satiowadahc#0> If no one replied add a D0.125 to your tools
03:08 PM lcnc-relay: <satiowadahc#0> Or whatever the width of your torch cut is
03:08 PM pcw-home: Velocity estimation is also limited by quadrature error (this can be improved by keeping 4 timestamps which I have done in the past but thats pretty fussy)
03:23 PM JT-Shop: Tom_L, so for halshow if it's opened in the config dir it opens that pref file
03:30 PM lcnc-relay: <roguish> JT: unless you specifically give a pref file name
03:31 PM JT-Shop: yes, the man file fails to mention that :)
03:33 PM Roguish: check in the [applications] section of the .ini docs
03:34 PM Roguish: same with the scope and halmete
03:34 PM Roguish: halmeter
03:35 PM JT-Shop: coo
03:35 PM JT-Shop: l
03:35 PM Roguish: I customize halscope files for each axis. easier that wayu
03:36 PM Roguish: ya can even edit the pref files.....
03:36 PM JT-Shop: I'll have to add that when I get flex done enough to actually do something
03:36 PM Roguish: i'm a lazy ass
03:36 PM JT-Shop: right now I'm working on status labels
03:37 PM Roguish: are progamming in pyth
03:37 PM Roguish: or what???
03:37 PM JT-Shop: python3 and pyqt6
03:38 PM Roguish: ok.... i have some time, so i might try to learn a little.....haha
03:38 PM JT-Shop: check out the flex code, I'm trying to comment more
03:39 PM JT-Shop: so Tom_L can learn
03:39 PM Roguish: comments are good... if ya look back into the early linuxcnc source, some of the files are well commented, some not
03:41 PM JT-Shop: my steam box exploded...
03:41 PM XXCoder: ow. you ok
03:43 PM Roguish: no vent????
03:44 PM Roguish: ooops
03:44 PM lcnc-relay: <JT (@jt-shop:matrix.org)> https://matrix.org/_matrix/media/v1/download/matrix.org/UkGIMzItkoATlmIbcWXcFXhL
03:45 PM lcnc-relay: <JT (@jt-shop:matrix.org)> https://matrix.org/_matrix/media/v1/download/matrix.org/AHhjiHWvRkXpMiPUYcOGPvVx
03:45 PM XXCoder: the bent part looks good
03:46 PM JT-Shop: https://www.youtube.com/watch?v=ANT51wUMqvg
03:46 PM XXCoder: is the cracked wood fixable?
03:46 PM Roguish: got to hand it to ya JT. you're not affraid to try stuff....
03:46 PM JT-Shop: I'm not going to worry about it at all
03:46 PM JT-Shop: I ain't scared
03:47 PM JT-Shop: it expanded due to the steam on one side and that's what split it
03:48 PM XXCoder: humidity changes, or pressure?
03:48 PM JT-Shop: steam
03:48 PM JT-Shop: watch the video
03:48 PM XXCoder: already watched that one yeserday
03:48 PM XXCoder: your channel is in my rss feed list for videos after all ;)
03:49 PM JT-Shop: :)
04:08 PM fdarling: pcw-home: would you please look at those two GitHub links I sent before? The second link is correct because it's a synchronous / blocking read and then it checks the buffer's bit, the first one however is queuing a read that won't be performed within that function block, but it's still checking the bit (from the legacy code's method)
04:09 PM fdarling: pcw-home: so what it's actually checking is the data being queued for writing, not anything being read
04:10 PM fdarling: pcw-home: they are having this "buff" variable set to the particular frame_sizes[] array entry that is passed into the function. So apparently the original version had the "side effect" of overwriting all of the frame sizes passed in with the RX status register values...
04:11 PM fdarling: but now, that side effect is delayed until the next HostMot2 packet exchange, and that code is checking for that result too early
04:11 PM fdarling: pcw-home, andypugh_: Andy Pugh requested that I raise a GitHub issue so we can discuss it there, which I think is fair...
04:13 PM fdarling: pcw-home: I still have the question though, where can I found out the data FIFO size/depth of 1024 bytes? (256 32-bit words?) Can this be queried from HostMot2 somehow?
04:28 PM pcw-home: That bit is a send count push error, not terrible important when its read
04:30 PM fdarling: pcw-home: yes, but what I am saying is that the code there isn't using the LinuxCNC HostMot2 API correctly because it's effectively checking the bit of a frame size being sent out, and not of the status register on the FPGA
04:31 PM fdarling: queue_write and queue_read take a source/destination buffer that is used much later on when the UDP packet is being sent/received, so the data must remain valid until then in the case of a write, and the data isn't to be trusted until then in the case of a read
04:33 PM fdarling: pcw-home: would I have to repeatedly write to the send data FIFO in order to "probe" how large it is? Is there a better way?
04:36 PM pcw-home: I dont think there is a direct way to determine the size other than filling the data FIFO till its full
04:36 PM pcw-home: All firmware in the field uses 1K so it could just be a constant
04:38 PM pcw-home: (not likely to matter for synchronous protocols like MODBUS with only 1 TX and RX frame)
04:39 PM pcw-home: So you are saying the mode register read is getting data from a previous packet
04:39 PM pcw-home: ?
04:52 PM fdarling: pcw-home: I am saying that the mode register read isn't getting any data from that read being queued during the call to "hm2_pktuart_send()", you have to check the destination buffer (frame_sizes[i] in this case) the *next* cycle after it's been populated
04:53 PM fdarling: https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/drivers/mesa-hostmot2/hm2_eth.c#L977
04:53 PM fdarling: you can see that queue read is only doing queuing, no actual reading
04:53 PM fdarling: (appending data to a read queue buffer)
04:56 PM fdarling: this is where the queue is used to actually send out a UDP packet: https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/drivers/mesa-hostmot2/hm2_eth.c#L835
04:57 PM pcw-home: So that code should be in the part that parses the returned data
04:57 PM fdarling: and finally where the received UDP packet triggers copying the data to the destination buffers: https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/drivers/mesa-hostmot2/hm2_eth.c#L943
04:58 PM fdarling: pcw-home: exactly, that error check needs to happen much later
04:58 PM fdarling: pcw-home: I think also the sending function needs to be broken into two phase: one where you attempt to push the data, then you must wait until the next cycle to see how much data was pushed successfully before sending the frame sizes that trigger transmission
04:59 PM fdarling: otherwise the frames during/after push errors will still maybe transmit, but be truncated and cause protocol issues
05:00 PM pcw-home: That does seem unlikely (unless you are doing non-synchronous protocols)
05:00 PM fdarling: you could instead push FIFO data, read the status, push more FIFO data, read the status, all in sequence so that you could later determine which frame's writes caused a FIFO problem
05:01 PM fdarling: what does the hardware do if you have not enough data in the transmit buffer, but you tell it to transmit a frame that is larger?
05:02 PM fdarling: is it "all or nothing" and it raises an error? Or is it best effort and it tries to transmit partially anyways?
05:03 PM pcw-home: You can pre-calculate all this and never make an FIFO error
05:03 PM fdarling: pcw-home: my plan is to, within my code, track how full the transmit FIFO is
05:03 PM pcw-home: the Error is mainly for driver debugging
05:03 PM fdarling: pcw-home: yes, but it's a bit concerning that I can't actually verify the FIFO's size/capacity
05:04 PM pcw-home: Well like I said its always 1024 bytes now
05:04 PM fdarling: pcw-home: the bug I am describing is a bug because it's checking something completely different than what it thinks it is, due to legacy code being changed only partially
05:05 PM fdarling: pcw-home: this other "break up the send" idea is a way to more gracefully handle failed sending, so you know how many frames were sent correctly. This is more of an enhancement than a bug fix
05:05 PM fdarling: pcw-home: all right, I'll put that as a define in my code
05:05 PM pcw-home: Yes, that check should be in the part that parses the return data
05:05 PM fdarling: pcw-home: the cost of that "enhancement" would be the API would be even more cumbersome, and it would delay stuff by yet another cycle
05:06 PM fdarling: pcw-home: because the PacketUART API doesn't have it's own scheduling, you'd have to call a followup function yourself next cycle
05:06 PM fdarling: because you are supposed to check the status registers at the beginning of PacketUART API use anyways, I'd argue the burden should be on the user of the API and that check should simply be removed (where it is currently)
05:09 PM fdarling: pcw-home: so what I am working on is a PacketUART abstraction layer that deals with sending packets and receiving the responses per-packet, reliably. It will also have a circular buffer to communicate with send requests from userspace, and also give the responses (with IDs matching their requests)
05:09 PM pcw-home: as long as the TX mode register is always read it can be checked where the RX data is processed
05:09 PM fdarling: this way the Modbus or other protocol logic can all be moved into userspace, but we still have high packet throughput because we can asynchronously queue many reads/writes (all packets being sent out) and deal with the salvo of responses later
05:10 PM fdarling: pcw-home: I don't understand what you mean by that last message
05:11 PM pcw-home: In general you cannot do that as modbus is strickly synchronous
05:12 PM pcw-home: I'm saying the check has to be in the same place RX data is processed (not where it is queued)
05:13 PM pcw-home: not where the request is queued I mean
05:17 PM pcw-home: (in modbus you need to wait for the remote response after every send or you will have collisions )
05:18 PM fdarling: pcw-home: ah, I see, you mean that you can't pipeline it because you can't do two sends before you get a receive
05:19 PM pcw-home: right
05:19 PM fdarling: pcw-home: does PacketUART not have any mechanism to wait? I thought that was the point...
05:20 PM fdarling: pcw-home: I know there is a configurable frame delay between received packets to have timeout to mark the "end" of a packet, but is there a mechanism to forward that information to the transmitting unit so that it knows to continue sending?
05:20 PM fdarling: like a "ping pong" state machine
05:21 PM pcw-home: PKTUART has no communication between RX and TX (other than echo suppression for half duplex links)
05:21 PM fdarling: :-(
05:22 PM pcw-home: That seem like that's really upper level protocol related and not something a UART should do
05:23 PM fdarling: pcw-home: if I had timestamps on the received frames and timestamped on the transmitted frames, I could sort it out in the upper levels
05:23 PM pcw-home: not sure what you are asking
05:23 PM fdarling: pcw-home: however, just their ordering within the transmit/receive realms isn't enough because a packet could be sent that has no response at all, and mess up the pairing from then on
05:24 PM fdarling: pcw-home: if I had the timestamps of when packets were sent (their start or end, I could calculate the other), and timestamps of when a packet was received (start and end might be quite different because the timing is not in our control, but probably close enough)
05:25 PM fdarling: then I would be able to figure out if a received packet was between two transmitted packets, and therefore it was the response to the transmission it came after
05:26 PM pcw-home: Not an issue with modbus
05:26 PM fdarling: obviously it could be an incredibly delayed response from a much earlier transmission, but this is always a problem even with normal synchronous Modbus code, you are relying on timeouts and relatively contiguous transmissions
05:26 PM fdarling: pcw-home: the idea is to be able to send more than one transmission and receive more than one reply per servo cycle of 1ms
05:28 PM pcw-home: The packet timeouts with modbus make the unlikely
05:28 PM fdarling: at 115,200 baud it seems we can only send 11.52 bytes per millisecond, so it may be that you'd only get 2 packets instead of 1 per cycle, which is not a super big speed boost
05:29 PM pcw-home: The remote response time is not instant either
05:29 PM fdarling: though as written currently, I think it's actually more like 1 packet every 3 servo thread cycles...
05:30 PM fdarling: pcw-home: yes, with half duplex the 11.52 byte times would have to be 5 send bytes + 6 waiting for reception at least...
05:31 PM fdarling: maybe I am optimizing the wrong thing :-/
05:31 PM fdarling: what I really want is an asynchronous API that has Modbus requests being sent out, and later you can check their responses, this way relatively slow userspace code can do bursts of reads/writes and see the responses later
05:31 PM fdarling: so that the synchronous aspect of Modbus is being handled elsewhere, ideally on the FPGA. In this case, next best thing is doing it in a realtime component...
05:32 PM fdarling: this API can be abstracted such that it communicates with a realtime component that does the Mesa card communication, or instead talks directly to a USB serial device (never leaving userspace)
05:33 PM fdarling: I am trying to unify Modbus VFD drivers so that they don't care if it's through the Mesa or over USB
05:40 PM pcw-home: Honestly I'm more interested in getting mesa-modbus working better and then add some device specific examples
05:40 PM pcw-home: most of the device specif stuff is just data/name munging
05:41 PM fdarling: pcw-home: I think instead of introducing yet another "meta compiler" to generate realtime components, we could have a single realtime component that communicated with a userspace component that was device specific, or parsed XML or whatever
05:42 PM fdarling: pcw-home: this is similar to what linuxcnc-ethercat does (but that is way more complicated). This would mean the device specific driver could also be written in Python (there is a demand for this, then you have no compiling you have to do)
05:45 PM pcw-home: I understand, I just don't like the idea of adding unpredictable latencies into the interface
05:47 PM pcw-home: and mesa-modbus it pretty close, it just needs local addresses, a way to mix types on multi coil read/writes and a few bug fixes to be pretty decent
05:49 PM NoSpark: are there any true hard realtime modbus devices?
05:49 PM fdarling: NoSpark: I don't know, but I doubt you can rely on it with Chinese VFDs ;-) maybe Yaskawa if you talked with Japan enough
05:50 PM pcw-home: (mixed types would allow most devices to have only 2 transactions per device)
05:50 PM fdarling: I've seen a lot of buggy Modbus stuff that was picky where you had to have a lot of radio silence if the link got corrupted, otherwise the remote device would just stop talking with you even if you had valid communication again
05:50 PM NoSpark: I have Yaskawa servo and spindle drives :) but they are mechatrolink
05:51 PM NoSpark: My point was that there would only be 2 or 3 cycles of jitter? wouldn't that be enough for all real world use cases of modbus?
05:52 PM NoSpark: unless you were planning on releasing some hard realtime modbus devices Peter?
05:52 PM fdarling: pcw-home: the "unpredictable latency" introduced by using some userspace stuff wouldn't really be that bad, because the API would make it so that the time sensitive Modbus communication wouldn't be done in userspace anyways, it would just be the business logic between transactions *where necessary*
05:53 PM fdarling: pcw-home: the idea is to queue multiple transactions and have them performed as quickly as possible by the realtime code, so that the userspace is just doing the higher level thinking
05:53 PM NoSpark: but a userspace component isn't going to be hard realtime anyway, is it?
05:53 PM fdarling: pcw-home: for example, there might be modbus devices where writing certain registers isn't allowed and puts it "further" into an error state if you don't first clear another error
05:54 PM fdarling: pcw-home: so you might have to read error status, and then decide to write an error clear and re-read the status
05:54 PM fdarling: pcw-home: rather than just blindly reading registers and writing registers (spamming if you will)
05:55 PM fdarling: thankfully most devices don't behave this way, you can read/write and the ability to do so isn't dependent on anything
05:55 PM pcw-home: I mean the hal --> device would have large timing uncertainties added by say a python userland hal componant
05:55 PM fdarling: so you can just always be reading to verify your writes worked, and then writing (hoping they will work), as well as reading stuff that is inherently just read-only information
05:56 PM fdarling: pcw-home: there will still be multi cycle delays anyways due to the PacketUART communication limitations, I don't know that a little extra latency due to Python/uspace will alter much how you have to code things
05:57 PM fdarling: like if you assert that a spindle should be turned off, then back on, if you do it fast enough it may never be "noticed" by the userspace driver
05:58 PM fdarling: however, all of my Modbus stuff is currently done purely in userspace anyways, and it works quite well. I just have to take care that the userspace defaults certain outputs certain ways when communication is severed, like the current spindle speed is output as zero after 2 seconds if no communication, because I know that the VFD would be watchdog faulted anyways
05:59 PM fdarling: you have to also be writing to shut the spindle off though, otherwise you might be keeping it on while thinking there is no communication because you aren't getting responses
05:59 PM fdarling: so that kind of logic is where the danger comes from in my opinion, where a component might have stagnant outputs
06:00 PM fdarling: I think the userspace component could have a "charge pump" style square wave output, and there could be realtime HAL components looking at this to OR a spindle fault signal along with the userspace components spindle fault output
06:01 PM fdarling: anyways, you see what I am going for, right? At least a incremental upgrade from doing it in userspace with USB serial adapters
06:01 PM fdarling: it won't be worse than that ;-) I think we can get nearly as good as Mesa-modbus too if the API is designed correctly, and then it will be much easier to maintain higher level VFD interaction drivers
06:09 PM pcw-home: Seem like a mess unless you made a unix device driver that emulates a com port with the pktuart (unless you want to re-write all the existing modbus components)
06:11 PM fdarling: pcw-home: I do want to rewrite all the existing modbus components, but that being said, a Linux kernel level tty device emulator would be a very simple way to adapt existing code. I found projects out there that can make virtual COM ports, the problem is that they are designed for application layer interacting with one of two looped-backed ports, no programmatic API to read/write data
06:12 PM fdarling: so I would probably still need a userspace component talking to a realtime component -- the realtime for PacketUART, and the userspace to relay the TX/RX stuff to/from a device driver that wasn't a "real" serial port but a loopback one, say port A, where another Modbus communication application was using port B
06:15 PM pcw-home: Well, the pktuart code should be OK for that (with the error check moved to the proper place)
09:26 PM srk| is now known as srk