[Emc-developers] I fixed a bit in wj200_vfd
Not sure how to share it with the project - past my pay grade. If the E-stop has not been started, it would spam the console with errors - now it gives the error once. -- Karl Schmidt EMail k...@lrak.net 3209 West 9th Street Ph (785) 841-3089 Lawrence, KS 66049 The point of modern propaganda isn't only to misinform or push an agenda. It is to exhaust your critical thinking, to annihilate truth. - Gary Kasparov component wj200_vfd "Hitachi wj200 modbus driver"; param rw unsigned mbslaveaddr "Modbus slave address"; pin in float commanded_frequency "Frequency of vfd"; pin in bit reverse"1 when reverse 0 when forward"; pin in bit run"run the vfd"; pin in bit enable "1 to enable the vfd. 0 will remote trip the vfd, thereby disabling it."; pin out bit is_running"1 when running"; pin out bit is_at_speed "1 when running at assigned frequency"; pin out bit is_ready "1 when vfd is ready to run"; pin out bit is_alarm "1 when vfd alarm is set"; pin out float motor_current "Output current in amps"; pin out float heatsink_temp "Temperature of drive heatsink"; pin out bit watchdog_out "Alternates between 1 and 0 after every update cycle. Feed into a watchdog component to ensure vfd driver is communicating with the vfd properly."; option userspace yes; option userinit yes; license "GPLv2 or greater"; ;; /* Userspace HAL component to control a Hitatchi WJ200 series VFD Written by Curtis Dutton, inspired by vfs11_vfd.c in linuxcnc Copyright (C) 2012 Curtis Dutton, OK Computers LLC This program is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation, version 2. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301-1307 USA. see 'man wj200_vfd' and the WJ200 section in the Drivers manual. */ #include #include #include #include #include #include #include #include typedef struct { uint8_t running; uint8_t ready; uint8_t direction; uint8_t at_speed; uint8_t alarm; float output_current; float sink_temp; uint16_t frequency; } wj200_status; /*sets the operating frequency of the vfd*/ bool wj200_setFrequency(modbus_t* ctx, uint16_t frequency) { return modbus_write_registers(ctx, 0x001, 1, ) > 0; } /*resets the trip status of the VFD*/ bool wj200_reset(modbus_t* ctx) { /*after the reset, the wj200 vfd seem to need a second before it will reply to more modbus commands*/ int rc = modbus_write_bit(ctx, 0x003, TRUE); sleep(1); return rc > 0; } bool wj200_setDirection(modbus_t* ctx, bool direction) { return modbus_write_bit(ctx, 0x001, direction) > 0; } bool wj200_trip(modbus_t* ctx) { return modbus_write_bit(ctx, 0x002, TRUE) > 0; } bool wj200_run(modbus_t* ctx, bool runBit) { return modbus_write_bit(ctx, 0x000, runBit) > 0; } // page 353 of manual bool wj200_getStatus(modbus_t* ctx, wj200_status* status) { int rc; uint8_t bits[16]; uint16_t registers[2]; uint16_t currentRegister[1]; uint16_t temperatureRegister[1]; /*read coils 0x000F thru 0x0019 in one step*/ rc = modbus_read_bits(ctx, 0x000F-1, 11, bits); if(rc < 0) { return false; } /*read the first 2 registers*/ rc = modbus_read_registers(ctx, 0x000, 2, registers); if(rc < 0) { return false; } // Read 1003h (output current) to 1019h (heatsink temp) rc = modbus_read_registers(ctx, 0x1003-1, 1, currentRegister); if(rc < 0) { return false; } rc = modbus_read_registers(ctx, 0x1019-1, 1, temperatureRegister); if(rc < 0) { return false; } status->running = bits[0]; status->direction = bits[1]; status->ready = bits[2]; status->alarm = bits[9]; status->at_speed = bits[5]; status->f
Re: [Emc-developers] [Kicad-developers] parts-list and BOM
On 04/21/2014 02:58 PM, Lorenzo Marcantonio wrote: On Mon, Apr 21, 2014 at 02:47:56PM -0500, Karl Schmidt wrote: There once was a way to get an XML BOM out of kicad - I was just sitting down to write a script to deal with it and I see it is no longer there. (Imagine the painful sound of a wolf howling).. UH? It's still there, in the BOM button in eeschema. It spits out the xml netlist. Why do you say is no longer there? My fault - I was looking for the BOM under the BOM menu.. Got the XLM file - the menus don't work as I would expect.. I would also like to pull in the doc link, but that does not appear to live in schematic.sch but only in the library.dcm file... That's true. The XML generator could be extended for that, probably. Version: (2013-dec-23)-testing Isn't this a *little* outdated ? That is what got pulled in bzr export $d/kicad lp:kicad/stable On 20140409 Karl Schmidt EMail k...@xtronics.com Transtronics, Inc. WEB http://secure.transtronics.com 3209 West 9th Street Ph (785) 841-3089 Lawrence, KS 66049 FAX (785) 841-0434 When everything is coming your way, it means you are in the wrong lane. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Linux going down a possibly dangerous, certainly un-welcome path
Not all that is happening is at the kernel level - there is more and more cruft being done at the microcode level (some due to threats of the folks in DC that want to be able to compromise any and all computers (like this will never blow up in their faces (idiots))). This has the effect of making run time of even assembly code non determent. Most likely powering down a peripheral chip will have a way to be disabled, but it needlessly increases complexity. I suppose in the end the market place will punish those that do stupid things - sadly that does not apply to the wizards in the government. A friend of mine was writing assembly code for an ARM chip where time of each cycle mattered. It turned out that if the code ran from the built in flash memory - sometimes the fetch would take longer than other - only moving the code to RAM solved the problem. What this means is that most modern hardware can not really do what I call 'determinant real time' - There are calls outside of user and system control that steal cycles and no way to predict the worst case. The good news is the hardware is mostly fast enough that we can still respond in micro seconds. I recently 'rooted' a droid device - and found that there was still code running that I did not have access to. I dumped that one and bought a Chinese droid device that lacked this 'feature'. (I assume that all devices are compromised - I don't think it prudent to ever store passwords on a connected device anymore.) Karl Schmidt EMail k...@xtronics.com Transtronics, Inc. WEB http://secure.transtronics.com 3209 West 9th Street Ph (785) 841-3089 Lawrence, KS 66049 FAX (785) 841-0434 99% of lawyers give the rest a bad name. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] status update: unified build/new RTOS support
On 07/12/2013 10:47 AM, Charles Steinkuehler wrote: Yes, and it should be noted that the number of problems due to documentation and support issues for the BeagleBone exploded after the Black was released due not only to the major changes to the hardware but also to the major structural changes on the software side caused by switching to the 3.8 kernel. IMHO, the new RTOS and unified build code represents a similar split for LinuxCNC, where a lot of existing documentation could be misleading or just plain wrong. There should be a well marked location to find the current documentation, and a clear indication that anything *NOT* found in the official location(s) is potentially outdated and wrong. Also a very important reason to put dates in documentation - I sometimes do a cnt-i in firefox in an attempt to find the date - but often it is misleading - something spit out by php.. Clue lines like: as of may 2012 or as of kernel x.y.z can be of great help down the road. Karl Schmidt EMail k...@xtronics.com Transtronics, Inc. WEB http://secure.transtronics.com 3209 West 9th Street Ph (785) 841-3089 Lawrence, KS 66049 FAX (785) 841-0434 The lack of a middle class is a good indicator of how corrupt a government is. kps -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Wichita LinuxCNC meeting
My takeaway - it is time to move to a modern RT kernel and to merge in Michael's and Charles' work. Karl Schmidt EMail k...@xtronics.com Transtronics, Inc. WEB http://secure.transtronics.com 3209 West 9th Street Ph (785) 841-3089 Lawrence, KS 66049 FAX (785) 841-0434 Truth is mighty and will prevail. There is nothing wrong with this, except that it ain't so. --Mark Twain -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Radical Ideas
The problem is, this is an international development. One specific non-cooperating person is in England. The right answer is to make a list of bits that would need to be re-written. Time with lawyers and courts are a psychic-energy-sink - re-doing sections of code, while time consuming, probably will use less time. Creating this list is a tedious and thankless job, but once the list is made, it might be surprising how fast the code can be re-written. Karl Schmidt EMail k...@xtronics.com Transtronics, Inc. WEB http://secure.transtronics.com 3209 West 9th Street Ph (785) 841-3089 Lawrence, KS 66049 FAX (785) 841-0434 Truth is mighty and will prevail. There is nothing wrong with this, except that it ain't so. --Mark Twain -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Licensing
On 06/10/2013 02:13 PM, Charles Steinkuehler wrote: I am positive the Debian directory controlling the package building needs a fair amount of love. I just finished getting kicad dailies to build in debian starting with a ubuntu debian directory - some notes: I would recommend focusing on getting into Debian first - there are about a dozen distributions that draw off of Debian besides Ubuntu and the Debian gate keepers make sure things actually conform to a real deb package. There is a mentoring system in Debian that can help whoever becomes the 'packager' and might be able to provide help with licensing problems. http://mentors.debian.net/ There is a second reason to get in Debian first - CNC systems need to be utterly stable - Ubuntu is focused on being bleeding edge. Debian stable provides a sane system for 'production' systems. Karl Schmidt EMail k...@xtronics.com Transtronics, Inc. WEB http://secure.transtronics.com 3209 West 9th Street Ph (785) 841-3089 Lawrence, KS 66049 FAX (785) 841-0434 Truth is mighty and will prevail. There is nothing wrong with this, except that it ain't so. --Mark Twain -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ 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 07/20/2012 09:38 PM, andy pugh wrote: On 21 July 2012 02:47, Charles Steinkuehlerchar...@steinkuehler.net wrote: My understanding is that one of the first things the servo thread does when it wakes up is poll for the current position from the appropriate lower-level (software step generator, mesa hardware, or whatnot). It is, but I think that the problem is that hardware frequency generators don't count their pulses. All depends on the hardware used and how it is configured - there is no reason this bit of electronics can't support position-counter registers. Depending on the uP chip - they can have lots of pulse generators - each counter has around a dozen config registers - they can be set up to count on the pulse outputs from one of the other counters that is set up to generate the pulses - or you can set it up to count pulses via interrupts. (The ARM cortex (thumb ) processors have very fast Interrupts.) Or using a cheap FPGA - the counter register is just more logic. The problem of doing this on a PC, is that the code running is not deterministic in time - the same instruction can take different amounts of time depending on what is going on, not only on the system level, but even on the micro-code level. Single chip uP systems are much more deterministic for doing real-time work - (even these can have differing instruction times - the time to read a flash location can sometimes take an extra cycle - but there are ways to work around this. ) In my mind, a single chip uP system, with just a small assembly program, could do the pulse generation busy work and make the position information available to the PC-system with time left over to play an audio stream. The question is if there is going to be a latency issue of bringing that position information back into the PC without any problematic latency - ( the outer loop is running much slower - so I doubt there is an issue. ) Karl Schmidt EMail k...@xtronics.com Transtronics, Inc. WEB http://secure.transtronics.com 3209 West 9th Street Ph (785) 841-3089 Lawrence, KS 66049 FAX (785) 841-0434 Any cat would tell you that you can only wash one paw at a time; while we try to do everything at once. -kps -- 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 07/20/2012 11:47 AM, Jon Elson wrote: Charles Steinkuehler wrote: My current plan is to bit-bang GPIO pins based on code from the parallel port driver, but adding a bit of electronics would probably make things much easier. What would the bit of electronics look like? Most of the single chip uP have hardware pulse generators built in that could easily generate the stepper pulses without jitter. Those chips are under $1 these days... Lattice now has a 1000 logic cell FPGA with built in configuration ROM and lots of other goodies for less than $2 .. (twice that in single quantities from digikey ) there is enough room to put a softcore CPU to talk to the controlling system etc.. If I have this pictured correctly - the controlling Linuxemc system would run the outer servo loop - and the hardware would generate the pulses for steppers? Hardware cost is no longer an issue. Karl Schmidt EMail k...@xtronics.com Transtronics, Inc. WEB http://secure.transtronics.com 3209 West 9th Street Ph (785) 841-3089 Lawrence, KS 66049 FAX (785) 841-0434 Any cat would tell you that you can only wash one paw at a time; while we try to do everything at once. -kps -- 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