Back
[03:15:16] <etvsteva> maybe PCW and mesanet!?
[04:45:45] <malcom2073> seb_kuzminsky: Have you used the bbb with linuxcnc(/machinekit)? It's a pretty terrible user experience. I run a 3d printer with it, and I'd *hate* to run a mill with it.
[04:49:08] <micges> malcom2073: why?
[04:55:44] <malcom2073> micges: It's too slow to give a decent user experience. The biggest issue I have is the delay in keyboard input. It's noticable primarly when incremental jogging multiple times when trying to touch off.
[04:57:23] <archivist> anything without enough memory, I get similar delays on an old PC that I have no more ram for it
[08:09:48] <jepler> the first thing you need to toss on an underpowered machine is a GUI with a preview
[08:14:25] <jepler> my understanding is that many of these little boards accelerate OpenGL ES but not traditional OpenGL; so a good project would be to make gremlin work with OpenGL ES.
[09:29:08] <pcw_home> apparently the BBB is noticeably slower than the Edison (500 MHz dual core Atom)
[10:07:28] <seb_kuzminsky> malcom2073: i have, and i agree it's very limited
[11:10:51] <jepler> andy or anybody with an opinion: on what kind of system is it important to home the spindle at power on?
[11:11:08] <jepler> is there a kind of spindle that can only "orient" after performing a homing sequence?
[11:19:29] <seb_kuzminsky> i had the same question
[11:27:11] <cradek> I don't know how any of our new orient stuff works
[11:28:52] <cradek> on my machine, it (the ladder) "homes" the carousel if needed, when you ask for Tx
[11:29:09] <cradek> it seems like the orient gcode should cause that to happen in the same way
[11:30:55] <pcw_home> presumably a servo spindle could orient a lot faster than home
[11:45:30] <cradek> I wonder what problem is being solved
[12:01:07] <ssi> my vmc has to orient before a TC
[12:01:12] <ssi> I haven't sorted out how to do it yet
[14:07:01] <etvsteva> I have trouble with locking rotary table
[14:07:38] <etvsteva> Lose axis.3.unlock signal before end of motion
[14:09:10] <etvsteva> Ac servo drive in step/dir configuration with 7i76
[14:12:31] <jepler> what version has the problem? do you know a specific older version which does not have the problem?
[14:12:56] <jepler> cradek: have you tested locked rotaries since the new TP went in?
[14:13:15] <cradek> surely sam has
[14:16:07] <etvsteva> before I had a dc servo with encoder and velocity closed loop
[14:16:17] <etvsteva> No problem
[14:16:40] <PCW> not sure why that would be any different
[14:17:02] <PCW> what linuxcnc versions on both?
[14:17:09] <etvsteva> Same
[14:17:21] <jepler> is your following error large?
[14:17:36] <etvsteva> Yes for testing purpose
[14:17:46] <jepler> I am not familiar with how movement of a locking axis finishes, but if it is based on when the *commanded* position arrives at the end point, it would explain your symptom.
[14:19:10] <etvsteva> Position command is stop when axis.3.unlock is off
[14:20:17] <etvsteva> Counts from stepgen is stil counting
[14:21:17] <cradek> there is a loopback
[14:21:30] <jepler> reviewing the source code, it does appear that the rotary is requested to lock again as soon as the commanded position reaches the endpoint
[14:21:40] <cradek> motion stops, it asserts "unlock", it waits for you to assert "is-unlocked" then motion continues
[14:21:53] <jepler> so if the following error is large, lock can be requested before the feedback position reaches the commanded position.
[14:22:10] <jepler> I recommend fixing your following error problem so that the following error is small
[14:22:18] <cradek> oh, I didn't read everything
[14:22:20] <cradek> thanks jepler
[14:22:38] <etvsteva> ok, that makes sense
[14:24:56] <PCW> following error on a step/dir system sounds like a configuration issue
[14:25:08] <cradek> yes
[14:25:26] <PCW> or is this a step/dir system with encoder feedback to linuxcnc?
[14:26:45] <etvsteva> No feedback from encoder
[14:27:08] <etvsteva> pure step/dir to ac servo
[14:27:36] <etvsteva> Ac servo is Chinese Xinje
[14:28:15] <etvsteva> X,y,z, same drive with no problem
[14:30:21] <PCW> ok so if you have any significant following error it sure sounds like a stepgen configuration issue
[14:35:00] <etvsteva> ok, thanks I'll try something the next day .
[15:57:36] <jepler> PCW: afaik all your newer cards have eeproms as the primary way to load the FPGA program. Do you imagine ever making new cards that lack an EEPROM for the bitfile?
[16:05:25] <PCW> Probably not
[16:05:41] <jepler> I'm just thinking, the current structure of hostmot2 makes cards that already have bitfiles in them the oddballs
[16:06:01] <jepler> in that there are a lot of things you can read from the running code once you can read the hostmot2 idrom but we code them in our source too
[16:07:14] <PCW> Yeah (that problem shows up with the 7I43 which _can_ have a config in its EEPROM)
[16:07:15] <PCW> and the 7I90 EPP mode (really the 7I43 and 7I90 EPP driver should be the same)
[16:10:05] <PCW> seems like a probe to test if the card is configured first might not be a bad idea
[16:10:32] <jepler> a possible item for post-2.7 work..
[16:18:55] <jepler> ever have a problem with eeprom write endurance in your testing cards? the advantage while developing the hostmot2 driver is definitely to cards that you can load a bitfile into at runtime
[16:31:11] <PCW> Not yet. the EEPROMS are supposed to be good for 10,000 writes
[16:33:24] <PCW> It would be good to have mesaflash be able to load a bitfile in a free EEPROM area and load the FPGA from there for first time bitfile testing
[16:34:39] <PCW> (so if the bitfile bricks the card, a power cycle will cure it)
[16:47:10] <micges_> PCW: maybe easiest is to add --addr parameter to --write
[16:47:37] <micges_> ./mf --write foo.bar --addr 0x4000
[16:47:52] <PCW> I was thinking something a bit less of a foot-gun
[16:49:13] <PCW> (that is, let mesaflash figure out free space )
[16:49:40] <PCW> or free bitfile locations I should say
[16:49:53] <micges_> ah, no address just tell to use free space not normal space
[16:50:26] <micges_> yes mf control used/free space
[16:51:15] <PCW> older 5i25/6i25s used a 8M EEPROM so only room for users and fallback areas
[16:51:59] <PCW> newer ones (and 7I92s ) use 16M EEPROS with room for 4 configs
[16:52:59] <PCW> even just the ability to reload the FPGA from the fallback area would help
[16:53:26] <micges_> I *think* mf will always write user at address of half eeprom
[16:54:06] <PCW> so to test a bitfile you load it into the fallback area and then
[16:54:08] <PCW> sudo mesaflash --device 5i25 --reload --fallback
[16:56:14] <PCW> not ideal to break your fallback config but normally recoverable by a power cycle
[16:56:44] <micges_> sudo mesaflash --device 5i25 --reload --fallback will work now
[16:57:10] <micges_> I mean is working now
[16:57:24] <PCW> It does? Ill have to try
[16:58:10] <micges_> if not I need to release 3.2
[16:59:44] <PCW> By golly it does work!
[17:01:13] <PCW> so the feature is basically there
[17:02:01] <micges_> --fallback is global switch changing target address of all functions, so every acrtion available on user area should be possible on fallbackarea
[17:02:50] <PCW> only enhancement I can see is adding --spare0 and --spare1 areas and mesaflash complaining if these areas are not available
[17:03:33] <PCW> (which takes a little math)
[17:05:28] <micges_> will config fit in spare on 8Mb flash?
[17:05:33] <micges_> on 5i25?
[17:05:55] <PCW> no, only 2 configs will fit in 8M
[17:06:34] <PCW> 2 XC6SLX9 configs
[17:06:36] <micges_> I see
[17:06:44] <micges_> yeah it's possible to add
[17:07:36] <PCW> 8 mbit so 1 Mbyte and XC6slx configs are ~340K
[17:07:48] <PCW> XC6SLX9
[17:08:06] <PCW> but 16 will hold 4
[17:08:13] <PCW> 16M
[17:08:31] <micges_> yeah
[17:08:47] <PCW> well 5 but that needs a fancier allocation scheme
[17:09:22] <PCW> not worth breaking compatibility
[17:09:34] <micges_> if you can have 4 configs and choose which one to boot from it's more than enough
[17:10:27] <micges_> great for 7i90: epp, spi, uart and sserial in one chip ;)
[17:10:41] <PCW> thats true of recent (last year or so) 5I25s 6I25s and all 7i90 and 7I92s
[17:11:12] <PCW> Yeah all on one chip but choosing is akward
[17:11:40] <micges_> for now yes, but it'\s possible
[17:12:34] <PCW> Ive often wondered if the ICAP stuff is smart enough to read pin states (so a boot ROM could choose a config image address)
[17:13:36] <PCW> _very_ little Xilinx documentation unfortunately
[17:15:14] <micges_> even for integrators like you?
[17:22:39] <PCW> I have not noticed that there are any tiers to Xilinx documentation availability but it could be
[17:23:21] <jepler> the partial bitstream loading feature of icap is intriguing too
[17:23:33] <jepler> if you could load the basic hostmot2 and then slot in an encoder here and a step generator there
[17:23:42] <jepler> but I have only glanced at high-level documentation about that
[17:38:42] <jepler> http://www.xilinx.com/support/documentation/application_notes/xapp151.pdf
[17:38:53] <jepler> wow this document all but explains the virtex bitstream format
[17:40:05] <jepler> anyway, with partial reconfiguration it seems like you could designate the whole device but one small bit as reconfigurable; the initial bitstream reads the state of your boot jumpers and then twiddles icap from inside the chip..
[17:52:07] <PCW> That's a good idea, you dont even need partial reconfig for that (if you have free config space for a full size boot ROM)
[17:53:55] <PCW> in fact if all bitfiles had this ability, which ever one loaded could switch to the jumper selected one
[17:55:49] <PCW> partial bitstream stuff is pretty painful because of the fixed LOCs