Re: [Emc-developers] motion planners plural and multiple X slides
Actually I can think of a much simpler solution which is doable right now (multiple LinuxCNC2 instances) with a Python HAL user component. The difference to what I laid out in my previous mail is: synchronisation is achieved at the HAL pin level, not at the 'precondition for issuing a message' level. This would work as follows: - beast ID's and sync point ID's are represented as HAL say S32 values, say 1...4 and 1..n respectively. - the userland component creates a syncpoint pin for each beast ID, so if we have beasts 1..4 there would be pins syncpoint1..syncpoint4 - there is a pin representing the 'self beast id' - the syncpoint1 pin (aka 'self syncpoint') is watched for change by the userland component, a change is broadcast to its peers. - the syncpoint2..syncpoint4 pins are driven by the userland component, which collects change messages from its peer components. - sync points shall be set in a monotonically ascending order by some language construct, eg, M66 for now This doesnt synchronize just yet, but it is a completely generic sync point value exchange vehicle. Actual synchronization could happen at the G code level for now, or in a separate HAL component: reach(syncpoint=5) means setting the 'self' syncpoint pin value. The userland component will pick it a change and broadcast it eventually. waitfor(beast=2,syncpoint=42) would retrieve the syncpoint2 value and loop until = 42, which is the asymmetric case if done in a single thread. waitfor(beasts=3,4,syncpoint=42) could be executed in several threads and would represent the rendezvous case. --- this isnt as elegant and general as the message precondition route, but it gets the job done I guess I will do a proof-of-concept with a Python HAL/zeromq messaging component, if just to accelerate fixing of our licensing issues;) other folks than might back-port this to Modbus if they so like -Michael Am 10.09.2012 um 07:25 schrieb Michael Haberler: Am 10.09.2012 um 04:56 schrieb EBo: On Sat, 8 Sep 2012 14:10:27 +0200, Michael Haberler wrote: Am 08.09.2012 um 12:46 schrieb Dave Caroline: While people are dreaming of new things for a version 3 I thought I would throw in a few items. I was staring at the sliding head thinking of the right thing to do and realised that the machine has interleaving of motion as well as coordinated motion While you could approximate that in the current system with effort in perhaps a special cam software system it would be better if it became built in somehow The way it currently works is a camshaft rotates once per part this drives cams for all slides, collets and accessory movement. this means while turning a dia another tool can be on a fast move into/out of position ready to start/finish cutting one tool could be cutting a dia while another cutting a taper That type of machine was programmed as starting/finishing an operation/move at an angle(time/number or revs of the total operation) of the cam just have to avoid crashes :) The machine also has mechanical gain(ratio) and offset so a class of parts can be made without remaking cams this also helps adjust tool wear/settings during production. I have seen other mentions on the list of machines that have multiple milling heads, I think this is the same problem normally the answer has been run multiple pcs and coordinate, this would be wrong on a single spindle sliding head lathe I found a working example on youtube http://www.youtube.com/watch?v=TDxvBHXklJo The rocker has two tools one being the cutting off tool so you can see the cycle time achievable with the method. shame about the flood lubricant and shaky camera work. Found a brochure for a later version on a forum http://www.practicalmachinist.com/vb/general/bechler-10-lathe-243337/ There have been a number of machines where a lot of axes are the same but just hold a different tool like this, there is a need to address their multiple axes in a consistent manner my machine has 4 X axes and a Z, not counting anything mounted on the front accessory block I have a couple of accessories one has three drills that can be brought into line with the spindle and the other has saws (screw head production probably) Dave Caroline I'm currently gathering what could be LinuxCNC3 requirements, and see how that can be folded into a plan and a time axis. Anyway. (what is actually the proper term for such a setup? multiple-spindle might be a bit narrow in focus) from the above I derive: - assuming Linuxcnc runs on single machine: Some key components which are currently singletons must become fully instantiable. These are: task, the interpreter embedded in task, the motion module, and the motion/task interface; iocontrol as long as it exists in its current form (this is a minimum list; probably I forgot some). Usrmotif probably could be coerced into supporting multiple motion instances, but
Re: [Emc-developers] Gwiz what the status?
Clearly nobody is using it lately :) I use it for my lathe and haven't noticed any problems. I was thinking that if this was embeddable in the screen and could access the python script style wizards that it would be a very handy winner. I was thinking the opposite. It would be nice if we could embed the linuxcnc backtrace into GWiz, so when we string together a few commands, we could get a visual display of what we are programming. And as you say, enhancing GWiz to support script wizards would be awesome. Add to that, the work that's been done for lathe roughing canned cycle, and it would be a pretty complete system for my needs. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] motion planners plural and multiple X slides
The notion of statically created HAL pins being used to represent sync points seems to cause a problem if sync points are within loops. They could no longer be reached monotonically. Regards, Ken On 9/10/2012 2:05 AM, Michael Haberler wrote: Actually I can think of a much simpler solution which is doable right now (multiple LinuxCNC2 instances) with a Python HAL user component. The difference to what I laid out in my previous mail is: synchronisation is achieved at the HAL pin level, not at the 'precondition for issuing a message' level. This would work as follows: - beast ID's and sync point ID's are represented as HAL say S32 values, say 1...4 and 1..n respectively. - the userland component creates a syncpoint pin for each beast ID, so if we have beasts 1..4 there would be pins syncpoint1..syncpoint4 - there is a pin representing the 'self beast id' - the syncpoint1 pin (aka 'self syncpoint') is watched for change by the userland component, a change is broadcast to its peers. - the syncpoint2..syncpoint4 pins are driven by the userland component, which collects change messages from its peer components. - sync points shall be set in a monotonically ascending order by some language construct, eg, M66 for now This doesnt synchronize just yet, but it is a completely generic sync point value exchange vehicle. Actual synchronization could happen at the G code level for now, or in a separate HAL component: reach(syncpoint=5) means setting the 'self' syncpoint pin value. The userland component will pick it a change and broadcast it eventually. waitfor(beast=2,syncpoint=42) would retrieve the syncpoint2 value and loop until = 42, which is the asymmetric case if done in a single thread. waitfor(beasts=3,4,syncpoint=42) could be executed in several threads and would represent the rendezvous case. --- this isnt as elegant and general as the message precondition route, but it gets the job done I guess I will do a proof-of-concept with a Python HAL/zeromq messaging component, if just to accelerate fixing of our licensing issues;) other folks than might back-port this to Modbus if they so like -Michael Am 10.09.2012 um 07:25 schrieb Michael Haberler: Am 10.09.2012 um 04:56 schrieb EBo: On Sat, 8 Sep 2012 14:10:27 +0200, Michael Haberler wrote: Am 08.09.2012 um 12:46 schrieb Dave Caroline: While people are dreaming of new things for a version 3 I thought I would throw in a few items. I was staring at the sliding head thinking of the right thing to do and realised that the machine has interleaving of motion as well as coordinated motion While you could approximate that in the current system with effort in perhaps a special cam software system it would be better if it became built in somehow The way it currently works is a camshaft rotates once per part this drives cams for all slides, collets and accessory movement. this means while turning a dia another tool can be on a fast move into/out of position ready to start/finish cutting one tool could be cutting a dia while another cutting a taper That type of machine was programmed as starting/finishing an operation/move at an angle(time/number or revs of the total operation) of the cam just have to avoid crashes :) The machine also has mechanical gain(ratio) and offset so a class of parts can be made without remaking cams this also helps adjust tool wear/settings during production. I have seen other mentions on the list of machines that have multiple milling heads, I think this is the same problem normally the answer has been run multiple pcs and coordinate, this would be wrong on a single spindle sliding head lathe I found a working example on youtube http://www.youtube.com/watch?v=TDxvBHXklJo The rocker has two tools one being the cutting off tool so you can see the cycle time achievable with the method. shame about the flood lubricant and shaky camera work. Found a brochure for a later version on a forum http://www.practicalmachinist.com/vb/general/bechler-10-lathe-243337/ There have been a number of machines where a lot of axes are the same but just hold a different tool like this, there is a need to address their multiple axes in a consistent manner my machine has 4 X axes and a Z, not counting anything mounted on the front accessory block I have a couple of accessories one has three drills that can be brought into line with the spindle and the other has saws (screw head production probably) Dave Caroline I'm currently gathering what could be LinuxCNC3 requirements, and see how that can be folded into a plan and a time axis. Anyway. (what is actually the proper term for such a setup? multiple-spindle might be a bit narrow in focus) from the above I derive: - assuming Linuxcnc runs on single machine: Some key components which are currently singletons must become fully instantiable. These are: task, the interpreter embedded
Re: [Emc-developers] Gwiz what the status?
Frank has been the only source of significant positive feedback on this effort. I've obviously failed to communicate how powerful, useful, and easy to use and expand this tool could be. (I guess all fathers think their children are beautiful.) I should probably do some more work on communication. Ken On 9/10/2012 3:23 AM, Frank Tkalcevic wrote: Clearly nobody is using it lately :) I use it for my lathe and haven't noticed any problems. I was thinking that if this was embeddable in the screen and could access the python script style wizards that it would be a very handy winner. I was thinking the opposite. It would be nice if we could embed the linuxcnc backtrace into GWiz, so when we string together a few commands, we could get a visual display of what we are programming. And as you say, enhancing GWiz to support script wizards would be awesome. Add to that, the work that's been done for lathe roughing canned cycle, and it would be a pretty complete system for my needs. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] motion planners plural and multiple X slides
On Mon, Sep 10, 2012 at 1:30 PM, Kenneth Lerman kenneth.ler...@se-ltd.com wrote: The notion of statically created HAL pins being used to represent sync points seems to cause a problem if sync points are within loops. They could no longer be reached monotonically. When slaved, master and slave spindles would be driven by the master loop with feedback from master, monitor the slaves following error it should match master until the part is parted then rise/fall, at that point reconnect the slaves loop. Dave Caroline -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] motion planners plural and multiple X slides
Am 10.09.2012 um 14:30 schrieb Kenneth Lerman: The notion of statically created HAL pins being used to represent sync points seems to cause a problem if sync points are within loops. They could no longer be reached monotonically. I wrote the below, but 'undecidable' might have to be replaced by 'broken' for that case ;) If rs274ngc had no control structures, just a linear flow, it would be possible to determine statically whether a given set of programs using sync primitives is deadlock-free. With control structures, IMO it is undecidable in the general case, but it might still be worth a stab; an 80/20 static analysis and coding guidelines probably could prevent most pitfalls. -m Regards, Ken On 9/10/2012 2:05 AM, Michael Haberler wrote: Actually I can think of a much simpler solution which is doable right now (multiple LinuxCNC2 instances) with a Python HAL user component. The difference to what I laid out in my previous mail is: synchronisation is achieved at the HAL pin level, not at the 'precondition for issuing a message' level. This would work as follows: - beast ID's and sync point ID's are represented as HAL say S32 values, say 1...4 and 1..n respectively. - the userland component creates a syncpoint pin for each beast ID, so if we have beasts 1..4 there would be pins syncpoint1..syncpoint4 - there is a pin representing the 'self beast id' - the syncpoint1 pin (aka 'self syncpoint') is watched for change by the userland component, a change is broadcast to its peers. - the syncpoint2..syncpoint4 pins are driven by the userland component, which collects change messages from its peer components. - sync points shall be set in a monotonically ascending order by some language construct, eg, M66 for now This doesnt synchronize just yet, but it is a completely generic sync point value exchange vehicle. Actual synchronization could happen at the G code level for now, or in a separate HAL component: reach(syncpoint=5) means setting the 'self' syncpoint pin value. The userland component will pick it a change and broadcast it eventually. waitfor(beast=2,syncpoint=42) would retrieve the syncpoint2 value and loop until = 42, which is the asymmetric case if done in a single thread. waitfor(beasts=3,4,syncpoint=42) could be executed in several threads and would represent the rendezvous case. --- this isnt as elegant and general as the message precondition route, but it gets the job done I guess I will do a proof-of-concept with a Python HAL/zeromq messaging component, if just to accelerate fixing of our licensing issues;) other folks than might back-port this to Modbus if they so like -Michael Am 10.09.2012 um 07:25 schrieb Michael Haberler: Am 10.09.2012 um 04:56 schrieb EBo: On Sat, 8 Sep 2012 14:10:27 +0200, Michael Haberler wrote: Am 08.09.2012 um 12:46 schrieb Dave Caroline: While people are dreaming of new things for a version 3 I thought I would throw in a few items. I was staring at the sliding head thinking of the right thing to do and realised that the machine has interleaving of motion as well as coordinated motion While you could approximate that in the current system with effort in perhaps a special cam software system it would be better if it became built in somehow The way it currently works is a camshaft rotates once per part this drives cams for all slides, collets and accessory movement. this means while turning a dia another tool can be on a fast move into/out of position ready to start/finish cutting one tool could be cutting a dia while another cutting a taper That type of machine was programmed as starting/finishing an operation/move at an angle(time/number or revs of the total operation) of the cam just have to avoid crashes :) The machine also has mechanical gain(ratio) and offset so a class of parts can be made without remaking cams this also helps adjust tool wear/settings during production. I have seen other mentions on the list of machines that have multiple milling heads, I think this is the same problem normally the answer has been run multiple pcs and coordinate, this would be wrong on a single spindle sliding head lathe I found a working example on youtube http://www.youtube.com/watch?v=TDxvBHXklJo The rocker has two tools one being the cutting off tool so you can see the cycle time achievable with the method. shame about the flood lubricant and shaky camera work. Found a brochure for a later version on a forum http://www.practicalmachinist.com/vb/general/bechler-10-lathe-243337/ There have been a number of machines where a lot of axes are the same but just hold a different tool like this, there is a need to address their multiple axes in a consistent manner my machine has 4 X axes and a Z, not counting anything mounted on the front accessory block I have a couple of accessories one has three
Re: [Emc-developers] motion planners plural and multiple X slides
Ignoring (for a moment) the means of communication, could the handshaking be as simple as a few more M-codes? M90 clear flags M91 P1 wait for blocking flag 1 to clear M92 P2 set blocking flag 2 M93 P2 release blocking flag 2 -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] motion planners plural and multiple X slides
could be we're reinventing some wheel here how do manufacturers of controls deal with synchronization? -m Am 10.09.2012 um 14:30 schrieb Kenneth Lerman: The notion of statically created HAL pins being used to represent sync points seems to cause a problem if sync points are within loops. They could no longer be reached monotonically. Regards, Ken On 9/10/2012 2:05 AM, Michael Haberler wrote: Actually I can think of a much simpler solution which is doable right now (multiple LinuxCNC2 instances) with a Python HAL user component. The difference to what I laid out in my previous mail is: synchronisation is achieved at the HAL pin level, not at the 'precondition for issuing a message' level. This would work as follows: - beast ID's and sync point ID's are represented as HAL say S32 values, say 1...4 and 1..n respectively. - the userland component creates a syncpoint pin for each beast ID, so if we have beasts 1..4 there would be pins syncpoint1..syncpoint4 - there is a pin representing the 'self beast id' - the syncpoint1 pin (aka 'self syncpoint') is watched for change by the userland component, a change is broadcast to its peers. - the syncpoint2..syncpoint4 pins are driven by the userland component, which collects change messages from its peer components. - sync points shall be set in a monotonically ascending order by some language construct, eg, M66 for now This doesnt synchronize just yet, but it is a completely generic sync point value exchange vehicle. Actual synchronization could happen at the G code level for now, or in a separate HAL component: reach(syncpoint=5) means setting the 'self' syncpoint pin value. The userland component will pick it a change and broadcast it eventually. waitfor(beast=2,syncpoint=42) would retrieve the syncpoint2 value and loop until = 42, which is the asymmetric case if done in a single thread. waitfor(beasts=3,4,syncpoint=42) could be executed in several threads and would represent the rendezvous case. --- this isnt as elegant and general as the message precondition route, but it gets the job done I guess I will do a proof-of-concept with a Python HAL/zeromq messaging component, if just to accelerate fixing of our licensing issues;) other folks than might back-port this to Modbus if they so like -Michael Am 10.09.2012 um 07:25 schrieb Michael Haberler: Am 10.09.2012 um 04:56 schrieb EBo: On Sat, 8 Sep 2012 14:10:27 +0200, Michael Haberler wrote: Am 08.09.2012 um 12:46 schrieb Dave Caroline: While people are dreaming of new things for a version 3 I thought I would throw in a few items. I was staring at the sliding head thinking of the right thing to do and realised that the machine has interleaving of motion as well as coordinated motion While you could approximate that in the current system with effort in perhaps a special cam software system it would be better if it became built in somehow The way it currently works is a camshaft rotates once per part this drives cams for all slides, collets and accessory movement. this means while turning a dia another tool can be on a fast move into/out of position ready to start/finish cutting one tool could be cutting a dia while another cutting a taper That type of machine was programmed as starting/finishing an operation/move at an angle(time/number or revs of the total operation) of the cam just have to avoid crashes :) The machine also has mechanical gain(ratio) and offset so a class of parts can be made without remaking cams this also helps adjust tool wear/settings during production. I have seen other mentions on the list of machines that have multiple milling heads, I think this is the same problem normally the answer has been run multiple pcs and coordinate, this would be wrong on a single spindle sliding head lathe I found a working example on youtube http://www.youtube.com/watch?v=TDxvBHXklJo The rocker has two tools one being the cutting off tool so you can see the cycle time achievable with the method. shame about the flood lubricant and shaky camera work. Found a brochure for a later version on a forum http://www.practicalmachinist.com/vb/general/bechler-10-lathe-243337/ There have been a number of machines where a lot of axes are the same but just hold a different tool like this, there is a need to address their multiple axes in a consistent manner my machine has 4 X axes and a Z, not counting anything mounted on the front accessory block I have a couple of accessories one has three drills that can be brought into line with the spindle and the other has saws (screw head production probably) Dave Caroline I'm currently gathering what could be LinuxCNC3 requirements, and see how that can be folded into a plan and a time axis. Anyway. (what is actually the proper term for such a setup? multiple-spindle might be a bit narrow in focus)
Re: [Emc-developers] Gwiz what the status?
The only info I can find on gwiz is on the wiki and seems to be quite short. It does seem to be aimed at non-programmers but lacks the usual screenshots that non-programmers might need in order to understand what it can do and what to do to use it. In all honesty I thought it was a dead project. John On 9/10/2012 7:34 AM, Kenneth Lerman wrote: Frank has been the only source of significant positive feedback on this effort. I've obviously failed to communicate how powerful, useful, and easy to use and expand this tool could be. (I guess all fathers think their children are beautiful.) I should probably do some more work on communication. Ken On 9/10/2012 3:23 AM, Frank Tkalcevic wrote: Clearly nobody is using it lately :) I use it for my lathe and haven't noticed any problems. I was thinking that if this was embeddable in the screen and could access the python script style wizards that it would be a very handy winner. I was thinking the opposite. It would be nice if we could embed the linuxcnc backtrace into GWiz, so when we string together a few commands, we could get a visual display of what we are programming. And as you say, enhancing GWiz to support script wizards would be awesome. Add to that, the work that's been done for lathe roughing canned cycle, and it would be a pretty complete system for my needs. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] motion planners plural and multiple X slides
Am 10.09.2012 um 15:11 schrieb andy pugh: Ignoring (for a moment) the means of communication, could the handshaking be as simple as a few more M-codes? M90 clear flags M91 P1 wait for blocking flag 1 to clear M92 P2 set blocking flag 2 M93 P2 release blocking flag 2 eventually I hope so, yes the tough part is making the synchonization abstraction solid and easy to use great example for a remapped code btw -m -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Raspberry Pi running EMC ???
here's linpack figures for the Rpi and an Intel D525. the D5252 is almost a factor of 6 faster than the Rpi for this benchmark (pull test code with wget http://www.netlib.org/benchmark/linpackc.new) pi@raspberrypi ~/tests $ gcc -O linpackc.c -lm -olinpackc pi@raspberrypi ~/tests $ ./linpackc Enter array size (q to quit) [200]: Memory required: 315K. LINPACK benchmark, Double precision. Machine precision: 15 digits. Array size 200 X 200. Average rolled and unrolled performance: Reps Time(s) DGEFA DGESL OVERHEADKFLOPS 16 0.66 90.91% 3.03% 6.06% 35440.860 32 1.33 88.72% 3.01% 8.27% 36021.858 64 2.64 88.26% 2.65% 9.09% 36622.222 128 5.28 89.58% 3.22% 7.20% 35874.830 256 10.56 88.92% 3.12% 7.95% 36170.096 mah@atom:~/src$ gcc -O linpackc.c -lm linpackc.c: In function 'main': linpackc.c:78: warning: ignoring return value of 'fgets', declared with attribute warn_unused_result mah@atom:~/src$ ./a.out Enter array size (q to quit) [200]: Memory required: 315K. LINPACK benchmark, Double precision. Machine precision: 15 digits. Array size 200 X 200. Average rolled and unrolled performance: Reps Time(s) DGEFA DGESL OVERHEADKFLOPS 128 0.96 86.46% 3.12% 10.42% 204403.101 256 1.91 87.96% 1.05% 10.99% 206807.843 512 3.82 87.43% 2.62% 9.95% 204403.101 1024 7.63 87.68% 2.36% 9.96% 204700.631 2048 15.26 87.42% 2.82% 9.76% 204254.660 Am 09.09.2012 um 23:35 schrieb Jon Elson: Kent A. Reed wrote: On 9/9/2012 1:54 PM, Jon Elson wrote: ... I have not reported any thread latencies for the Beagle. Sorry, Jon. Looking back I see you were talking about how fast one could drive GPIO pins. My memory is getting rustier by the day. And, mine isn't getting better by the day, either. You've mentioned floating-point performance in the past. Do we have any benchmarking for that? There certainly are standard benchmarks that can be run on Linux systems that could be quite useful. I haven't seen anybody post numbers, but likely they already exist on the web, somewhere. A quick search didn't show any published results comparing say, the Beagle Board's OMAP 3430 against an Intel Atom, for instance, which would be a good comparison. ... As for interrupts and timers, if you accept that you have to add FPGA hardware to the CPU for step generation, encoder counting or whatever, then you can have that add-on produce the interrupts for the RT thread at any rate you choose. In my philosophy, Horatio, this is a perfectly acceptable requirement and I look forward to products from you and Peter. I accept as well that they may have to be tailored to specific ARM-based systems for the reasons just mentioned. I have built an adapter to connect my boards to the Beagle and emulate the IEEE-1284 par port in software. It worked, and wasn't horribly slow, compared to a PC. I didn't worry about the interrupt line, but on the Beagle, at least, ANY GPIO pin can be set up as an interrupt. I have not even looked at the code required to make that actually work (especially since the lack of RTAI was the reason work in that direction stopped.) Jon -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] gremlin error report gives....an error!
File /home/chris/emc2-dev/lib/python/gremlin.py, line 351, in report_gcode_error + str(seq) + of\n + filename + \n + error_str + \n) IOError: [Errno 9] Bad file descriptor It actually does print the gcode error and file name properly... Is this because hal_gremlin needs a bit of a touch - I thought I read that somewhere... Chris M Chris, I haven't seen that error on my system, but I'm not using hal_gremlin either. Error reporting on program load is an odd thing as there's no clever way to incorporate it into gremlin. Here I just passed the pertinent information (filename, line number, error type) off to a method that gui writers could easily subclass. That way you could display the error on a gtk.label or similar widget. +def report_gcode_error(self, result, seq, filename): + error_str = gcode.strerror(result) + sys.stderr.write(G-Code error in + os.path.basename(filename) + \n + Near line ++ str(seq) + of\n + filename + \n + error_str + \n) + I don't know why you're seeing that error with hal_gremlin, and later this week when I have time I'll try to reproduce it (an easy fix would be to simply remove the offending call to sys.stderr.write, which I put in as a default). In the meantime, I suggest subclassing the gremlin.report_gcode_error method in your gscreen.py code and diverting the information to wherever you think it would be appropriately displayed. Rogge -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Raspberry Pi running EMC ???
On 9/10/2012 10:45 AM, Michael Haberler wrote: here's linpack figures for the Rpi and an Intel D525. the D5252 is almost a factor of 6 faster than the Rpi for this benchmark (pull test code with wget http://www.netlib.org/benchmark/linpackc.new) pi@raspberrypi ~/tests $ gcc -O linpackc.c -lm -olinpackc pi@raspberrypi ~/tests $ ./linpackc Enter array size (q to quit) [200]: Memory required: 315K. LINPACK benchmark, Double precision. Machine precision: 15 digits. Array size 200 X 200. Average rolled and unrolled performance: Reps Time(s) DGEFA DGESL OVERHEADKFLOPS 16 0.66 90.91% 3.03% 6.06% 35440.860 32 1.33 88.72% 3.01% 8.27% 36021.858 64 2.64 88.26% 2.65% 9.09% 36622.222 128 5.28 89.58% 3.22% 7.20% 35874.830 256 10.56 88.92% 3.12% 7.95% 36170.096 mah@atom:~/src$ gcc -O linpackc.c -lm linpackc.c: In function 'main': linpackc.c:78: warning: ignoring return value of '€˜fgets'€™, declared with attribute warn_unused_result mah@atom:~/src$ ./a.out Enter array size (q to quit) [200]: Memory required: 315K. LINPACK benchmark, Double precision. Machine precision: 15 digits. Array size 200 X 200. Average rolled and unrolled performance: Reps Time(s) DGEFA DGESL OVERHEADKFLOPS 128 0.96 86.46% 3.12% 10.42% 204403.101 256 1.91 87.96% 1.05% 10.99% 206807.843 512 3.82 87.43% 2.62% 9.95% 204403.101 1024 7.63 87.68% 2.36% 9.96% 204700.631 2048 15.26 87.42% 2.82% 9.76% 204254.660 Am 09.09.2012 um 23:35 schrieb Jon Elson: Kent A. Reed wrote: ... You've mentioned floating-point performance in the past. Do we have any benchmarking for that? There certainly are standard benchmarks that can be run on Linux systems that could be quite useful. I haven't seen anybody post numbers, but likely they already exist on the web, somewhere. A quick search didn't show any published results comparing say, the Beagle Board's OMAP 3430 against an Intel Atom, for instance, which would be a good comparison. ... Thanks, Michael. I'm *still* waiting for my RPi so I spent some time looking up benchmarking info regarding ARM vs the world. (Caveat: I know very well that benchmarking is the art of lying with confidence.) Because of my FORTRAN upbringing I have a tendency to rely on the Whetstone benchmark but the choice of suite may not matter as much as the choice of compiler, even more so with ARMs because of the compromises made by software folks with different versions of the instruction set. To start, are you running Raspbian Linux or Debian Linux? versions? I will kick in the benchmarks I run on my BeagleBoardXM and ASUS AT5NM10-I while I wait. Regards, Kent -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Raspberry Pi running EMC ???
Michael Haberler wrote: here's linpack figures for the Rpi and an Intel D525. the D5252 is almost a factor of 6 faster than the Rpi for this benchmark Thanks much for doing this! Not a great result, though. My feeling is that the Atom processors are marginal for LinuxCNC, especially in cases with long programs or contouring, where the slowness would be more obvious. So, if the Pi is 1/6th that speed, that will not be good at all. Exactly how this compares on LinuxCNC, where there is also a lot of non-FP code, isn't clear. If LinuxCNC was run with the GUI on another system, it might be OK, and for special projects which are not typical machines, it might be fine. Jon -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Raspberry Pi running EMC ???
Am 10.09.2012 um 18:07 schrieb Kent A. Reed: On 9/10/2012 10:45 AM, Michael Haberler wrote: here's linpack figures for the Rpi and an Intel D525. ... Thanks, Michael. I'm *still* waiting for my RPi so I spent some time looking up benchmarking info regarding ARM vs the world. (Caveat: I know very well that benchmarking is the art of lying with confidence.) Because of my FORTRAN upbringing I have a tendency to rely on the Whetstone benchmark but the choice of suite may not matter as much as the choice of compiler, even more so with ARMs because of the compromises made by software folks with different versions of the instruction set. To start, are you running Raspbian Linux or Debian Linux? versions? Raspbian. This looks very complete in terms of packages available. This kernel is stock: Linux raspberrypi 3.2.27+ #102 PREEMPT Sat Sep 1 01:00:50 BST 2012 armv6l GNU/Linux I'm just cross-compiling the kernel to see how that goes, it might be agonizing on the Rpi;looks good so far -m I will kick in the benchmarks I run on my BeagleBoardXM and ASUS AT5NM10-I while I wait. Regards, Kent -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Raspberry Pi running EMC ???
Point of view is everything. You said: the D5252 is almost a factor of 6 faster than the Rpi for this benchmark I would have said the Rpi is only a factor of 6 slower for this benchmark :-) It's also a factor of 20 smaller (a guess) and uses a factor of 20 less power (also a guess). Regards, Ken On 9/10/2012 10:45 AM, Michael Haberler wrote: here's linpack figures for the Rpi and an Intel D525. the D5252 is almost a factor of 6 faster than the Rpi for this benchmark (pull test code with wget http://www.netlib.org/benchmark/linpackc.new) pi@raspberrypi ~/tests $ gcc -O linpackc.c -lm -olinpackc pi@raspberrypi ~/tests $ ./linpackc Enter array size (q to quit) [200]: Memory required: 315K. LINPACK benchmark, Double precision. Machine precision: 15 digits. Array size 200 X 200. Average rolled and unrolled performance: Reps Time(s) DGEFA DGESL OVERHEADKFLOPS 16 0.66 90.91% 3.03% 6.06% 35440.860 32 1.33 88.72% 3.01% 8.27% 36021.858 64 2.64 88.26% 2.65% 9.09% 36622.222 128 5.28 89.58% 3.22% 7.20% 35874.830 256 10.56 88.92% 3.12% 7.95% 36170.096 mah@atom:~/src$ gcc -O linpackc.c -lm linpackc.c: In function 'main': linpackc.c:78: warning: ignoring return value of '€˜fgets'€™, declared with attribute warn_unused_result mah@atom:~/src$ ./a.out Enter array size (q to quit) [200]: Memory required: 315K. LINPACK benchmark, Double precision. Machine precision: 15 digits. Array size 200 X 200. Average rolled and unrolled performance: Reps Time(s) DGEFA DGESL OVERHEADKFLOPS 128 0.96 86.46% 3.12% 10.42% 204403.101 256 1.91 87.96% 1.05% 10.99% 206807.843 512 3.82 87.43% 2.62% 9.95% 204403.101 1024 7.63 87.68% 2.36% 9.96% 204700.631 2048 15.26 87.42% 2.82% 9.76% 204254.660 Am 09.09.2012 um 23:35 schrieb Jon Elson: Kent A. Reed wrote: On 9/9/2012 1:54 PM, Jon Elson wrote: ... I have not reported any thread latencies for the Beagle. Sorry, Jon. Looking back I see you were talking about how fast one could drive GPIO pins. My memory is getting rustier by the day. And, mine isn't getting better by the day, either. You've mentioned floating-point performance in the past. Do we have any benchmarking for that? There certainly are standard benchmarks that can be run on Linux systems that could be quite useful. I haven't seen anybody post numbers, but likely they already exist on the web, somewhere. A quick search didn't show any published results comparing say, the Beagle Board's OMAP 3430 against an Intel Atom, for instance, which would be a good comparison. ... As for interrupts and timers, if you accept that you have to add FPGA hardware to the CPU for step generation, encoder counting or whatever, then you can have that add-on produce the interrupts for the RT thread at any rate you choose. In my philosophy, Horatio, this is a perfectly acceptable requirement and I look forward to products from you and Peter. I accept as well that they may have to be tailored to specific ARM-based systems for the reasons just mentioned. I have built an adapter to connect my boards to the Beagle and emulate the IEEE-1284 par port in software. It worked, and wasn't horribly slow, compared to a PC. I didn't worry about the interrupt line, but on the Beagle, at least, ANY GPIO pin can be set up as an interrupt. I have not even looked at the code required to make that actually work (especially since the lack of RTAI was the reason work in that direction stopped.) Jon -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Raspberry Pi running EMC ???
Alex dug this out on Xenomai on the Rpi and it is an interesting read: http://www.raspberrypi.org/phpBB3/viewtopic.php?t=12368p=154691 A quick (very quick) test shows typical latencies in the order of 20-30uS and peaking at ~70uS for user space tasks. The kernel space latencies are even better and look pretty solid at around 15uS. That could mean Rpi+Xenomai is actually usable with soft stepgen (assuming it doesnt run out of steam on doing FP in motion) also it seems this kernel has the hires timer issue resolved: If power management is enabled, the 1MHz System Timer will be used. If power management is disabled, the ARM Timer, configured to run at 250MHz, will be used instead. -m Am 10.09.2012 um 18:48 schrieb Jon Elson: Michael Haberler wrote: here's linpack figures for the Rpi and an Intel D525. the D5252 is almost a factor of 6 faster than the Rpi for this benchmark Thanks much for doing this! Not a great result, though. My feeling is that the Atom processors are marginal for LinuxCNC, especially in cases with long programs or contouring, where the slowness would be more obvious. So, if the Pi is 1/6th that speed, that will not be good at all. Exactly how this compares on LinuxCNC, where there is also a lot of non-FP code, isn't clear. If LinuxCNC was run with the GUI on another system, it might be OK, and for special projects which are not typical machines, it might be fine. Jon -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Raspberry Pi running EMC ???
I took a moment and looked at that thread. Those numbers are worst case. Another posted ~2us with little load. It would be nice to set up a latency tester which artificially mucked with some threads to get realistic numbers. Hmmm... is there any instrumentation in the simulation code to calculate latency statistics with actual setups and configurations? That would be rather interesting... On Mon, 10 Sep 2012 19:55:58 +0200, Michael Haberler wrote: Alex dug this out on Xenomai on the Rpi and it is an interesting read: http://www.raspberrypi.org/phpBB3/viewtopic.php?t=12368p=154691 A quick (very quick) test shows typical latencies in the order of 20-30uS and peaking at ~70uS for user space tasks. The kernel space latencies are even better and look pretty solid at around 15uS. That could mean Rpi+Xenomai is actually usable with soft stepgen (assuming it doesnt run out of steam on doing FP in motion) also it seems this kernel has the hires timer issue resolved: If power management is enabled, the 1MHz System Timer will be used. If power management is disabled, the ARM Timer, configured to run at 250MHz, will be used instead. -m Am 10.09.2012 um 18:48 schrieb Jon Elson: Michael Haberler wrote: here's linpack figures for the Rpi and an Intel D525. the D5252 is almost a factor of 6 faster than the Rpi for this benchmark Thanks much for doing this! Not a great result, though. My feeling is that the Atom processors are marginal for LinuxCNC, especially in cases with long programs or contouring, where the slowness would be more obvious. So, if the Pi is 1/6th that speed, that will not be good at all. Exactly how this compares on LinuxCNC, where there is also a lot of non-FP code, isn't clear. If LinuxCNC was run with the GUI on another system, it might be OK, and for special projects which are not typical machines, it might be fine. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] gremlin error report gives....an error!
On Mon, Sep 10, 2012 at 10:58:28AM -0500, Daniel Rogge wrote: +def report_gcode_error(self, result, seq, filename): + error_str = gcode.strerror(result) + sys.stderr.write(G-Code error in + os.path.basename(filename) + \n + Near line + + str(seq) + of\n + filename + \n + error_str + \n) + Btw regarding this block - why not to use string from axis with parameter substitution instead of manual assembly + ... +...? I don't know why you're seeing that error with hal_gremlin My bet is that it's instantiated from HAL and thus have all descriptor closed. It's not a problem, i've post appropriate hal_gremlin function tomorrow. Pavel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Raspberry Pi running EMC ???
On 9/10/2012 10:45 AM, Michael Haberler wrote: here's linpack figures for the Rpi and an Intel D525. the D5252 is almost a factor of 6 faster than the Rpi for this benchmark (pull test code with wget http://www.netlib.org/benchmark/linpackc.new) pi@raspberrypi ~/tests $ gcc -O linpackc.c -lm -olinpackc pi@raspberrypi ~/tests $ ./linpackc Enter array size (q to quit) [200]: Memory required: 315K. LINPACK benchmark, Double precision. Machine precision: 15 digits. Array size 200 X 200. Average rolled and unrolled performance: Reps Time(s) DGEFA DGESL OVERHEADKFLOPS 16 0.66 90.91% 3.03% 6.06% 35440.860 32 1.33 88.72% 3.01% 8.27% 36021.858 64 2.64 88.26% 2.65% 9.09% 36622.222 128 5.28 89.58% 3.22% 7.20% 35874.830 256 10.56 88.92% 3.12% 7.95% 36170.096 mah@atom:~/src$ gcc -O linpackc.c -lm linpackc.c: In function 'main': linpackc.c:78: warning: ignoring return value of '€˜fgets'€™, declared with attribute warn_unused_result mah@atom:~/src$ ./a.out Enter array size (q to quit) [200]: Memory required: 315K. LINPACK benchmark, Double precision. Machine precision: 15 digits. Array size 200 X 200. Average rolled and unrolled performance: Reps Time(s) DGEFA DGESL OVERHEADKFLOPS 128 0.96 86.46% 3.12% 10.42% 204403.101 256 1.91 87.96% 1.05% 10.99% 206807.843 512 3.82 87.43% 2.62% 9.95% 204403.101 1024 7.63 87.68% 2.36% 9.96% 204700.631 2048 15.26 87.42% 2.82% 9.76% 204254.660 I wanted to point to http://elinux.org/Rpi_Performance earlier but I couldn't remember where I had seen the numbers. They reported marginally (ca 15 percent) better LINPACK performance with their RPi at 700MHz and managed ca 60KFLOPS by overclocking to 1000MHz. Your numbers also don't seem out of line with http://www.ptxdist.org/development/kernel/arm-benchmarks-20100729_en.html, although they tested a BeagleBoard. I remember feeling ok in the Spring about my BeagleBoard-XM because I knew the Raspberry Pi ARM11 cpu uses the older ARMv6 instruction set*; then I felt queazy when I realized the RPi includes VFP; now I am bemused to read the following (from http://vanshardware.com/2010/08/mirror-the-coming-war-arm-versus-x86/ which tested yet another ARM system) Oddly enough, during our performance optimization experiments, Neon generated the same level of double-precision performance as the VFP, while doubling the VFP’s single-precision performance. When we asked ARM about this, company representatives replied, “NEON improves FP performance significantly. The compiler should be directed to use NEON over the VFP.” Finally, from mathtest.c comes this 2004 comment by Paul Comer (drawn from notes by Fred Proctor) /* math functions are: extern double sin(double);used in posemath, siggen, noncartesian kins extern double cos(double);used in posemath, siggen, noncartesian kins extern double tan(double);not used in RT extern double asin(double); not used in RT extern double acos(double); used in posemath noncartesian kins extern double atan2(double, double); used in posemath noncartesian kins extern double sinh(double); not used in RT extern double cosh(double); not used in RT extern double tanh(double); not used in RT extern double exp(double);not used in RT extern double log(double);not used in RT extern double log10(double); not used in RT extern double pow(double, double);not used in RT extern double sqrt(double); used in tc, segmot, noncartesean kins. extern double ceil(double); used in segmot emcpid extern double floor(double); used by siggen segmot extern double fabs(double); used a lot in RT extern double ldexp(double, int); not used in RT extern double sincos(double, double *, double *); Is called at four places in posemath - None of the resulting functions are used in EMC. Extras: extern int isnan(double); Not used directly in RT - But is called by several (all ?) of the floating point math functions. */ Obviously, this ignores the pedestrian functions like add, subtract, multiply, divide, negate, and compare, but do you suppose this is still an accurate accounting of the floating-point math functions used in LinuxCNC? Regards, Kent -- Live Security
Re: [Emc-developers] Raspberry Pi running EMC ???
On Mon, 2012-09-10 at 16:41 -0400, Kent A. Reed wrote: On 9/10/2012 10:45 AM, Michael Haberler wrote: here's linpack figures for the Rpi and an Intel D525. the D5252 is almost a factor of 6 faster than the Rpi for this benchmark (pull test code with wget http://www.netlib.org/benchmark/linpackc.new) pi@raspberrypi ~/tests $ gcc -O linpackc.c -lm -olinpackc pi@raspberrypi ~/tests $ ./linpackc Enter array size (q to quit) [200]: Memory required: 315K. LINPACK benchmark, Double precision. Machine precision: 15 digits. Array size 200 X 200. Average rolled and unrolled performance: Reps Time(s) DGEFA DGESL OVERHEADKFLOPS 16 0.66 90.91% 3.03% 6.06% 35440.860 32 1.33 88.72% 3.01% 8.27% 36021.858 64 2.64 88.26% 2.65% 9.09% 36622.222 128 5.28 89.58% 3.22% 7.20% 35874.830 256 10.56 88.92% 3.12% 7.95% 36170.096 mah@atom:~/src$ gcc -O linpackc.c -lm linpackc.c: In function 'main': linpackc.c:78: warning: ignoring return value of '€˜fgets'€™, declared with attribute warn_unused_result mah@atom:~/src$ ./a.out Enter array size (q to quit) [200]: Memory required: 315K. LINPACK benchmark, Double precision. Machine precision: 15 digits. Array size 200 X 200. Average rolled and unrolled performance: Reps Time(s) DGEFA DGESL OVERHEADKFLOPS 128 0.96 86.46% 3.12% 10.42% 204403.101 256 1.91 87.96% 1.05% 10.99% 206807.843 512 3.82 87.43% 2.62% 9.95% 204403.101 1024 7.63 87.68% 2.36% 9.96% 204700.631 2048 15.26 87.42% 2.82% 9.76% 204254.660 I wanted to point to http://elinux.org/Rpi_Performance earlier but I couldn't remember where I had seen the numbers. They reported marginally (ca 15 percent) better LINPACK performance with their RPi at 700MHz and managed ca 60KFLOPS by overclocking to 1000MHz. Your numbers also don't seem out of line with http://www.ptxdist.org/development/kernel/arm-benchmarks-20100729_en.html, although they tested a BeagleBoard. I remember feeling ok in the Spring about my BeagleBoard-XM because I knew the Raspberry Pi ARM11 cpu uses the older ARMv6 instruction set*; then I felt queazy when I realized the RPi includes VFP; now I am bemused to read the following (from http://vanshardware.com/2010/08/mirror-the-coming-war-arm-versus-x86/ which tested yet another ARM system) A most interesting link! It does look like ARM8 does need to pick up some processing power. The really interesting thing was the embedded crypto capability of a couple of the chips. Too bad we don't need that kind of power. ;-) Still the only thing that really counts is enough speed to handle motion. We should be able to pass the GUI off to a dedicated X-term and likewise boards from Jon and Peter are clearly capable of driving the steppers/servos and handling discrete I/O. Better cpu's seem to be coming; the tough part is in the waiting. :-) Dave Oddly enough, during our performance optimization experiments, Neon generated the same level of double-precision performance as the VFP, while doubling the VFP’s single-precision performance. When we asked ARM about this, company representatives replied, “NEON improves FP performance significantly. The compiler should be directed to use NEON over the VFP.” Finally, from mathtest.c comes this 2004 comment by Paul Comer (drawn from notes by Fred Proctor) /* math functions are: extern double sin(double);used in posemath, siggen, noncartesian kins extern double cos(double);used in posemath, siggen, noncartesian kins extern double tan(double);not used in RT extern double asin(double); not used in RT extern double acos(double); used in posemath noncartesian kins extern double atan2(double, double); used in posemath noncartesian kins extern double sinh(double); not used in RT extern double cosh(double); not used in RT extern double tanh(double); not used in RT extern double exp(double);not used in RT extern double log(double);not used in RT extern double log10(double); not used in RT extern double pow(double, double);not used in RT extern double sqrt(double); used in tc, segmot, noncartesean kins. extern double ceil(double); used in segmot emcpid extern double floor(double); used by siggen segmot extern double fabs(double); used a lot in RT extern double ldexp(double, int); not used in RT extern double sincos(double, double *, double *); Is called at four places in
Re: [Emc-developers] motion planners plural and multiple X slides
On 10 September 2012 20:29, EBo e...@sandien.com wrote: I do not think will work. Your blocking flag needs to be read and set with an atomic operation (ie. single instruction). Why isn't a block atomic in the context? -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Gwiz what the status?
Clearly nobody is using it lately :) I use it for my lathe and haven't noticed any problems. I was thinking that if this was embeddable in the screen and could access the python script style wizards that it would be a very handy winner. I was thinking the opposite. It would be nice if we could embed the linuxcnc backtrace into GWiz, so when we string together a few commands, we could get a visual display of what we are programming. And as you say, enhancing GWiz to support script wizards would be awesome. Add to that, the work that's been done for lathe roughing canned cycle, and it would be a pretty complete system for my needs. Frank: You must be using an older version of EMC2 or fixed the scripts up to use linuxcnc. The version in the repository was broken for linuxcnc. Some up to date docs need to be written. If you have some time maybe you could write up the basic use in the wiki? And if Ken could document how to add new wizards... Chris M -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] motion planners plural and multiple X slides
On Tue, 11 Sep 2012 01:32:59 +0200, andy pugh wrote: On 10 September 2012 20:29, EBo e...@sandien.com wrote: I do not think will work. Your blocking flag needs to be read and set with an atomic operation (ie. single instruction). Why isn't a block atomic in the context? Did you intend your read/set to be atomic? If so then you and I are on the same page. If not then I was just trying to make a point. From your reaction it seems that you already know what I meant and it is just a point of us agreeing that it needs to me there and I did not understand that your read honored the necessity. Other than that, reading a value does not modify the value in an atomic operation so that the next one does not slip through. Let me see if I cam make this any sense... thread #1 thread #2 wait until flag1 unset some instruction... some instruction...wait until flag1 unset set flag1 some instruction... some other instruction... set flag1 now both threads are in the critical region if the the thread context switch happens in the wrong place. I'm assuming at this point that we are both agreed that this is a bad idea, but the sublty is in how either of us pseudo-coded the problem. Now addressing a separate issue of block[ing] atomic operations. There are times you want blocking and/or non-blocking operations. My wait was intended to be blocking (ie not unblocked). But that is besides the point. Can we agree that atomicity of lock/semaphore/mutex is useful/necessary here? EBo -- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Raspberry Pi running EMC ???
Artec has built a 6 dof NURB in FPGA, and hacked EMC2 (sim) to feed it. An open source solution for FPGA would be fascinating to me, but the problem might have already been solved. What do you want to do that is different than their solution? On Tue, 11 Sep 2012 00:23:44 +0300, Topi Rinkinen wrote: Hi, I have RPi playing Internet radio, and another one waiting for some fun activities. I have been thinking integrating a small FPGA or CPLD with RPi, especially targeted to CNC or motor control applications. For starters one could use Lattice's MachXO2 based evaluation kits (USD 30), and connect it to GPIO connector of RPi. But I don't know anything about EMC2 software architecture, so I cannot start easily. My background is in FPGA design, and I think I can quite quickly develop a library of needed VHDL modules to be run on CPLD/FPGA. If someone other could compile a list of activities that need FPGA's realtime and rough specifications, I can start coding the modules. BR, -Topi On Mon, 2012-09-10 at 16:41 -0400, Kent A. Reed wrote: On 9/10/2012 10:45 AM, Michael Haberler wrote: here's linpack figures for the Rpi and an Intel D525. the D5252 is almost a factor of 6 faster than the Rpi for this benchmark (pull test code with wget http://www.netlib.org/benchmark/linpackc.new) pi@raspberrypi ~/tests $ gcc -O linpackc.c -lm -olinpackc pi@raspberrypi ~/tests $ ./linpackc Enter array size (q to quit) [200]: Memory required: 315K. LINPACK benchmark, Double precision. Machine precision: 15 digits. Array size 200 X 200. Average rolled and unrolled performance: Reps Time(s) DGEFA DGESL OVERHEADKFLOPS 16 0.66 90.91% 3.03% 6.06% 35440.860 32 1.33 88.72% 3.01% 8.27% 36021.858 64 2.64 88.26% 2.65% 9.09% 36622.222 128 5.28 89.58% 3.22% 7.20% 35874.830 256 10.56 88.92% 3.12% 7.95% 36170.096 mah@atom:~/src$ gcc -O linpackc.c -lm linpackc.c: In function 'main': linpackc.c:78: warning: ignoring return value of '€˜fgets'€™, declared with attribute warn_unused_result mah@atom:~/src$ ./a.out Enter array size (q to quit) [200]: Memory required: 315K. LINPACK benchmark, Double precision. Machine precision: 15 digits. Array size 200 X 200. Average rolled and unrolled performance: Reps Time(s) DGEFA DGESL OVERHEADKFLOPS 128 0.96 86.46% 3.12% 10.42% 204403.101 256 1.91 87.96% 1.05% 10.99% 206807.843 512 3.82 87.43% 2.62% 9.95% 204403.101 1024 7.63 87.68% 2.36% 9.96% 204700.631 2048 15.26 87.42% 2.82% 9.76% 204254.660 I wanted to point to http://elinux.org/Rpi_Performance earlier but I couldn't remember where I had seen the numbers. They reported marginally (ca 15 percent) better LINPACK performance with their RPi at 700MHz and managed ca 60KFLOPS by overclocking to 1000MHz. Your numbers also don't seem out of line with http://www.ptxdist.org/development/kernel/arm-benchmarks-20100729_en.html, although they tested a BeagleBoard. I remember feeling ok in the Spring about my BeagleBoard-XM because I knew the Raspberry Pi ARM11 cpu uses the older ARMv6 instruction set*; then I felt queazy when I realized the RPi includes VFP; now I am bemused to read the following (from http://vanshardware.com/2010/08/mirror-the-coming-war-arm-versus-x86/ which tested yet another ARM system) Oddly enough, during our performance optimization experiments, Neon generated the same level of double-precision performance as the VFP, while doubling the VFP’s single-precision performance. When we asked ARM about this, company representatives replied, “NEON improves FP performance significantly. The compiler should be directed to use NEON over the VFP.” Finally, from mathtest.c comes this 2004 comment by Paul Comer (drawn from notes by Fred Proctor) /* math functions are: extern double sin(double);used in posemath, siggen, noncartesian kins extern double cos(double);used in posemath, siggen, noncartesian kins extern double tan(double);not used in RT extern double asin(double); not used in RT extern double acos(double); used in posemath noncartesian kins extern double atan2(double, double); used in posemath noncartesian kins extern double sinh(double); not used in RT extern double cosh(double); not used in RT extern double tanh(double); not used in RT extern double exp(double);not used in RT extern double log(double);not used in RT extern double log10(double); not used in RT extern double pow(double, double);
Re: [Emc-developers] Emc-developers Digest, Vol 77, Issue 17
You are welcome... I'm tired enough that I cannot think through this, but if the following example honors full concurrency then I agree. Can you set up an experimental test bench that fully exercises a number of critical sections across threads? I am not sure if it would work in Glade or not, but I am curious if it can be made to work. As a note, I am really interested in working minimal cases and not what if's. Do you have time to hammer on this? EBo -- On Mon, 10 Sep 2012 07:31:09 +0200, ro...@abcnc.se wrote: Thnks for your input EBo! Part of the project is promised to take shape this week. That means it's in the nutsbolt-phase, at least partially. The GUI is prioritized and Glade is suggested to be used. Pythons TCP-inteface is also in the pipe. Tried this yesterday: ** # Echo server program import socket HOST = '' # Symbolic name meaning all available interfaces PORT = 50007 # Arbitrary non-privileged port s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.bind((HOST, PORT)) s.listen(1) conn, addr = s.accept() print 'Connected by', addr while 1: data = conn.recv(1024) if not data: break conn.sendall(data) conn.close() *** with it's clientpart. I guess this code could run with Glade? And then we have the issue of interfacing LinuxCncRsh(LCRsh) to Glade. It's functions: - Create socket conections to all targets - Load all target files. (max 10) - Start all targets - Monitor all systems over LCRsh (Synchronism will be solved separately in this stage.) This could I guess, all be done in Glade/Python creating the following GUI items: - TCP address list - G-code source file list - per target main state indicators a la Axis: From: EBo e...@sandien.com Subject: Re: [Emc-developers] LinuxCNC-cluster run by Modbus etc... To: emc-developers@lists.sourceforge.net Message-ID: e2f5e5508933c7823a609083b35cf...@mail.swcp.com Content-Type: text/plain; charset=UTF-8; format=flowed I guess that the only thing I can add at this point is that you can have course- or fine-grain parallelism. I can easily see how to do #3 below using a course-grained approach by writing separate programs in each one of the work envelope regions, and then having a master command the machines in basically a task based approach (and wait until each of the tasks are done before moving forward). The nice thing about this is that the workload can be adjusted on the fly to accommodate networks of machines that do the same operation. All that being said, I did not think that that is what you had in mind... On Sat, 8 Sep 2012 11:39:49 +0200, Roger Holmquist wrote: Hello again! Well, I have to comment my last slighly cryptic post and focus on the subject. The subject is a cluster of syncchronized LinuxCnc-driven machines. That means U have to add ccertain functionality beyond LinuxCNC. 1) Remote controlling every machine 2) Remotely feed it with Gcode 3) Take care of synchronism, fault states and collision risks. 4) ( A GUI ) 1) Seem to be solved by using LinuxCncRsh who can - Load a gcode-file - execute it - monitor it - recieve certain fault states - terminante it 2) could be done over ftp -or- by dripfeeding over linuxcncrsh 3) is the hard part, possible support may come from subsystems like - MODBUS SW - REDIS - Ladder logic - TCP socket managing SW, may be included in some of the above packages - Something else? The preferred configuration is supposed to be Master-Slave with one of the machines configured as master. The GUI should be an non-systemdependent addition, U should be able to run the system from terminal just like LinuxCncRsh Could it be simplified? / Roger 7 sep 2012 kl. 19:42 skrev emc-developers-requ...@lists.sourceforge.net: Yes the emcrsh is renamed and linuxCNC who is installed, seem to leave my request to open that nonexisting task in silence or is it any logfile somewhere? linuxcncrsh runs just fine, haven't checked all functionality yet but it looks good. Now I need an engine with tcp-connectivity for synchronism and error-handling... And a GUI... I think I mentioned that earlier, MODBUS was named, seem to be integrated somewhere already after some brief encounter in the linuxCNC jungle -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net
Re: [Emc-developers] motion planners plural and multiple X slides
Michael, Not sure where to start or finish here. It will be interesting to see how HAL and Thread interact to deal with critical regions I can see it working. The question is how elegantly we can get this to work. I think it might be as simple as a semaphore (stretched between two user defined G codes -- g91/g92...) Now I need to get back to work... I hope this all works out. EBo -- On Mon, 10 Sep 2012 07:25:53 +0200, Michael Haberler wrote: Ebo, Michael, I agree. I wanted to add one thing to your modular abstraction that I hope will help. it's good to hear the idea isnt considered totally outlandish Instead of thinking about separate machines, maybe we can think about named groups of actuators and sensors operating together. This would definitely be needed, yes Terminology: how do we name that? A good short term would be great. (I'll use 'beast' for the rest of this message to encourage finding of a better term;) IMO it encompasses: a HAL+threads instance with a messaging interface (in the CNC context: with some mechanical entity attached to it) Currently there is no name for it, and since it's a singleton now and implicit, no data structure exists to support a reference to it. You could separate a spindle from an XYZA table if you do not threading. On the other hand, if you have a pick and place robot feeding a couple of routers, then each machine has a group of XYZ's (which may or may not) be driven by separate controllers, but are always handled by separate process threads. This way a router with a dual gantry could be abstracted to run independently, but with the added process/thread/group message communication. right, this would amount to sending different message streams to different beasts, in an unsynchronized manner; just fire off some rs274ngc scripts in different instances. Brainstorming on controlling a 6 head tool screw machine (like in the video someone posted recently). Each axis/tool has a dependency graph. As soon as all depend operations are completed I can insert the new one in the queue. Now check against the different tools crashing against each other you can have them move basically independently if they do not overlap either spatially or temporally. syncing multiple beasts came up repeatedly I think any primitive supporting this must be at the beast level, as the rs274ngc level is too macroscopic - a word may be decomposed into many messages. --- Note that there is *some* implicit synchronization of motion commands in place right now; there are two classes of commands: - sequenced: e.g. 2 feed moves a,b: b only starts with a complete (at the message interface level; the fact that blending may happen is irrelevant here) - immediate: pause, abort, feed hold .. the term used in the code is 'issuing a command', and whether a 'command can be issued' at a given point in time is determined by the command *type*, and the sequencing decisions are based on serial numbers and completion indications the issuing logic is partly in task, and partly in motion (and complex to understand) Now lets rename the expression 'OK to issue a command' to 'precondition for execution of a command is true'; if we can generalize this precondition for issuing a bit we might get the multi-beast synchronization almost for free, as this is just another messaging interaction (yeah, right, free code, sure ;) As for synchronization primitives, I can think of two forms: - beast A waits for beast B to reach a certain point in the execution, meaning A blocks for B but not vice versa (asymmetric sync) - beast A and beast B join at a sync point. This is symmetric synchronization, and basically the pthreads_join(), or the Ada rendezvous for you DoD oldtimers;) Again: a good term is needed for sync point. I could think of the following language constructs: Asymmetric sync in 'named beast A' would require something like: reach(x) # the current beast A has reached sync point 'x'; this is nonblocking and basically a broadcast or message of reached(A,X) to all beasts in beast B we would have: waitfor(A,x) # B blocks until beast A has executed 'reach(x)' Symmetric multi-party rendezvous is the implicit combination of a sync point and a list of waitfor's: join(y, B,C,D) # A blocks until B, C, and D also have reached 'x' eg beast B would have: join(x, A,C,D) I'll see whether I can cook up some Petri net drawings, those are great at describing such stuff concisely, FSM's dont cut it. Actually I'll see how I can wire this into my Python mockup. Deadlock detection and prevention is another issue, which suggests thinking about identification and ordering of sync points. If rs274ngc had no control structures, just a linear flow, it would be possible to determine statically whether a given set of programs using sync primitives is deadlock-free. With
