@Stuff4Pi: I'd be happy to have a look at your problem if you give me more detais.
@veryevil: I'm not sure I know how to fix this. Below is an attempt. In addition to downloading this version, you need to create a file named display.conf at the root, and in it write "use_distance_buffer = false" without the quotes. - grbv-20130806T1506-32bits.zip - grbv-20130806T1506-64bits.zip
@Squonk: Unfortunately my compiler generates binaries that won't run on XP. To resolve that I'd have to change my build setup to use an older compiler, but I cannot do that right now.
@Sleepwalker3: I just uploaded a version where I tried to slash as many unneeded dependencies as I could regarding win32 APIs. It should work better on Vista. Here are the links: - [s:]grbv-20130806T0015-32bits.zip[/s:] - [s:]grbv-20130806T0015-64bits.zip[/s:]
It's the same problem as before, only appearing differently because of the code changes. It's because one of the libraries depends on stuff that come with Windows 7, here DirectX11, in your previous report some other Windows 7 feature. This is something I can work around, but it may take some time.
@Sleepwalker3: Thanks for the report. I think it's a Vista-specific bug. I have an idea on how to fix it, I'll give it a try and post an update. Unfortunately I don't have a Windows Vista machine to test it.
Well, most of it is written in Lua or relatively portable C code. However I use the win32 API (or thin wrappers for Lua) for all the window creation and user input. I tried to modularize cleanly, so most of it is in gui.lua and render.lua. So the biggest task to run the application on Linux would be to rewrite these two modules, port the OpenGL binding module I wrote so that it compiles on Linux, and recompile every other modules and their dependencies. The main event loop is using a Lua module that I already ported to Linux.
All in all this is doable, but I haven't used a Linux desktop computer for years, and don't plan to in the near future, so I won't be the one doing it just because I cannot run a Linux OpenGL program. That being said I'd be glad to help anyone wanting to give it a try. I use Linux daily through the command line on headless machines so I can help with compilation at the very least.
As for running the app on Wine, maybe I can give some explanation on your problem. I recently switched to Visual Studio 2012 Express (ie. VC++ 11.0) for my compilation, and the new VC runtime (the MSVCR110.dll in your logs) depends on kernel features introduced in Windows Vista. The LCMapStringEx function (still in your logs) seems to be one of these features. That's why my Windows version requires at least Vista. I don't know Wine well enough, but maybe it's starting in some "XP mode" and you can configure it in "Vista mode" or "7 mode" instead.
Unfortunately the problem seems to be related to the lack of OpenGL 4.x support on your computer. I didn't find an easy way to disable OpenGL 4.x on mine, so I have to fix the problem blindly, which is never easy.
Would you have some time for a short debug session through IRC or some instant messaging system? I would send you alternative code to try out.
Over the course of the last 5 months I developped an application to visualize Gerber data. The goal was primarily to review Gerber files before sending them to a PCB fabrication house. It is very similar to the Mayhew Labs online Gerber viewer, except it's offline (and has a few different features).
My tool is program for Windows (32bits or 64bits) that use OpenGL for visualization (you will need a decent/recent video card). You can simply drag and drop Gerber files on it, or use the command line to configure it more deeply. I set up a page explaining most of that and giving download links :
I wrote the tool primarily for my own usage. In particular I wanted to visualize milling data to validate my PCB panelization scripts (which are still work in progress). However it may be useful to other people so I took some time to package it. Everything is open source, steal whatever you want for your own projects.
Please feel free to report bugs and request new features, I'm eager to improve that tool if that can help the community. Note that there is a high chance that the tool cannot display anything on your hardware, but it should report an error and I'd be very grateful if you would report it to me.
As a teaser here is an example screenshot of one of my boards. More are available on the webpage linked above.
For the past few years (I'm unfortunately not the kind of people releasing a project a week, or even a month), I've been working on some small boards that are supposed to work as a group (one per actuator in a large and complex robot). So I'm planning to do some panelization to reduce PCB fab costs, and to speed up assembly.
I don't have board cutting equipment (and I'd like to avoid cutting after assembly since the boards are densely populated), so I'd like to pre-cut the boards in the panel, with breakable tabs. I know Seeed and others accept milling data, but I can't find much information about how to design these Gerber files for the milling.
So can anyone explain in detail what sort of data should be in the milling files? Are the dark area of the milling file assumed to be removed with the CAM dealing with the details, or are the apertures and traces in the Gerber data directly translated to CAM directives?
Ideally I'd like information independent of the CAD tool, since I'm panelizing the Gerber files of single boards myself with custom scripts (that I'll release once I'm done with the milling aspects).
Alternatively if you have an example involving milling slots, with the Gerber files and pictures of the resulting boards, that should be enough to get me started.
[quote author="nowait"]I did that and it now seems fine, just not totally sure why :)[/quote]
Without a resistor to limit the current going into the base, you probably exceeded the maximum current that the PIC can source, which may have put the PIC pin in an unstable state (also possibly damaging it).
I'm considering making some panelized PCB with a size similar to yours, but I don't know what to draw in the milling Gerber files. I can't find which file corresponds to the milled slot in the Gerber files you put on github. Can you tell me which one it is?
[quote author="arthurb"]Just a hint: Take a look on Linear variable differential transformer. It's a great kind of sensor.[/quote]
One of the papers about sensorless solenoid position control I found use such a LVDT sensor as a reference. It appeared so large in the diagrams and pictures I assumed it wouldn't fit in my space constants. I'll have a look at the principle to see if that's true.
[quote author="Bertho"]At 48V you should consider an active gate driver. Maybe even use an NMOS combined with a high-side driver (which has a charge-pump to charge the gate).[/quote]
I don't really know what's an active gate driver. Can you point at some examples? In my current revision I'm using an Allegro A3949 that probably has one embedded, but that's a full bridge so it's overkill, a little under my desired spec (36V, 2.8A peak current), and it's not very easy to source.
Quote
Your switch losses are proportional to the ton and toff timing. Depending your current requirements, you may have a MOSFET with considerable gate capacitance (1..50nF). A simple resistor driver may result in an RC-time too large and you'll spend a virtual eternity in the linear region while switching, burning a lot of power in the process.
Ideally I'd like to drive up to 3A at 48V, or something between 50 and 100W. As for the timing, I'm currently using a 1kHz PWM, considering a 10kHz maximum, and I'd like between 10 and 100 samples per cycle. So anything shorter than 1µs I don't really care, and if switch time goes up to 10µs or even some more I can probably live with it.
And as for the word "loss", I'm not sure what you meant exactly. I care a bit about temperature and reaction time, but not at all about power consumption, this thing is not going to run on batteries anytime soon.
[quote author="Bertho"]However, your setup still needs to fix the Vgs breakdown voltage of the high-side PMOS and resistor power consumption, which also adds a bit to complexity.
I'd argue that fixing the high-side switch is easier. ;-)[/quote]
OK, I'll go that route then (and I'll try to post on eeweb before I sends the PCB to fab, just in case).
As for the Vgs limit, I found out about it in many datasheets, and then I found some parts that had much higher limits. But it's so easy to fix with a voltage divider I'll go that route (also you're right it may be beneficial to have the same resistance to both the high and low potentials).
Also thanks for reminding about the pull-up (and now pull-down) dissipated power. I put +24V in the diagram, but I'd like my board to be able to handle up to 48V. I'll make sure that whatever power is drawn by these resistors stays within their operational range, but I have to keep them low enough so that the gate charges or discharges quickly, since any significant delay as compared to the PWM period may ruin the inductance measurement.
[quote author="deuplonicus"]I know this isn't ideal, but have you considered hall effect current sensing?[/quote]
Well, actually my initial idea was using an external Hall sensor attached to the plunger. The current iteration of the board (the one using a full H bridge) has a connector for a sensor, precisely for that.
But I discovered the sensorless position control principle while browsing for solenoids, and it seemed much more appropriate for two reasons. The first one is that my solenoids have an external armature (they are tubular solenoids) and the magnetic field outside is rather low.
The second one is that I plan to have several independent soleneoids close to each other in my final robot, so their external (residual) magnetic fields would interfere with each other. It won't hopefully affect the solenoids operation, but I think it would mess any external magnetic field measurement.
[quote author="Bertho"][quote author="doub"]I use high side driving with a P-channel MOSFET (it's open to discussion)[/quote]
High-side switching is normally only used if you require a ground-reference for the switched load. It is usually cheaper to use a N-channel and switch the low-side. You can still do current measurements in the source-path to ground since the voltage drop will be low.[/quote]
I need to measure current when the solenoid is turned off, because it's the rate of current change that I'm interested in, both when the solenoid is charging and when it's discharging.
Quote
If you go for low-side switching, be sure to choose an N-channel with a low enough Vgs threshold or setup a gate-driver to get the proper Vgs level for saturation (and be sure to take the current measurement voltage drop into account).
With low side switching there are two cases. If I put the current sensing resistor between the ground and the MOSFET, I cannot measure current in the PWM off phase. If I put the resistor between the solenoid and the MOSFET, then the voltage at the resistor pins will be near the supply voltage during the off phase, which imply that the op amp it's connected to is capable of handling it.
So either I do high side switching with nice and simple current sensing, or I do low side switching with complicated current sensing. The real question is, is the improvement in transistor characteristics from PMOS to NMOS worth the added sensing complexity?
