On Thursday, September 29, 2011 2:07 AM, "andy pugh" <bodge...@gmail.com> wrote: > Is this expected? It has me baffled.
It is "expected", although not at all intuitive. It is not at all unique to rawcounts, every pin would behave the same, although with many it would be a lot harder to see the behavior. > Initially this was noticed when trying to configure the bldc component > with a pseudo-absolute encoder, but I see the same thing with my > jogwheel encoder. > > set the jogwheel rawcounts to 300 > halmeter shows hm2_5i23.0.encoder.02.rawcounts as 300 > halcmd net enc hm2_5i23.0.encoder.02.rawcounts conv_s32_float.0 > halmeter shows hm2_5i23.0.encoder.02.rawcounts = 0 ???! > move jogweel, halmeter shows 40 > delsig enc -> halmeter goes back to 300. The delsig tipped me off as to what is going on. It is an implementation detail that normally doens't get noticed. I bet if you move the jogwheel after the delsig, it will jump to 40 (plus or minus whatever distance you moved the wheel). Here is what is happening: HAL pins are implemented as pointers. When a pin is connected to a signal (a net), the pointer points to a memory location that is associated with the net. If there are four pins connected to the net, that means there are four pointers that reference the same memory location. Each component reads or writes to the signal by dereferencing the pointer. Since they all point to the same place, they all access the same data. That is fundamentally what a signal/net is all about. But what about an unconnected pin? We could have used NULL pointers for that, but doing so would require special case code to detect the null pointer and either discard a write or fake a read. Instead, there is a dummy memory location associated with every pin. When the pin isn't connected to a signal, the pointer points at the dummy. Every pin has its own dummy. When you connect the pin to a signal, the pointer gets changed to point at the signal. When you delete the signal, the pointer gets changed again to point back at the dummy. Neither the component itself, nor halmeter, nor halcmd, or anything else, really knows or cares if the pointer is pointing at the dummy (unconnected pin) or at the memory associated with a signal (pin connected to a net). And in normal operation, where you connect everything once and then leave it connected, it works perfectly. But when you start making and breaking connections on the fly, you can sometimes see behind the curtain. In your case, here is what happened: You loaded the driver, the pin was unconnected, pointing to dummy. You moved the jogwheel, the driver updated the dummy, to 300. You connected the pin to a net, pointer moves the the net memory. Net memory contains zero, halmeter shows that. You moved the jogwhee, the driver updated the net memory. You deleted the signal, the pointer goes back to the dummy, which is still at 300. I'm a little surprised that the halmeter tracked the change from 40 to 300. I would have expected the halmeter to continue watching the memory associated with the signal, even after the signal was deleted (another glimpse behind the curtain). Did you use one instance of halmeter the whole time, or did you start halmeter, observe the reading, then stop it and issue another hal command? I think you could actually see things better if you used several halmeters. Load the driver, start a halmeter and observe the pin - this meter will be watching the dummy value. Then, without stopping the halmeter, connect the net and start another halmeter. That one should be observing the memory associated with the net. First one will be showing 300, second one zero. When you move the wheel, second one will change. When you delete the signal, the second meter will still be looking at it, but the first meter will be the one to change when you move the wheel. > > The actual thing I am trying to fathom is that when I load my test hal > file, the encoder rawcounts shows as 11000, but if I delsig and re-net > to bldc it shows 0. The delsig and re-net mean the pin pointer is now pointing to a different place. I think in many cases you wouldn't be able to see the effect, because most components are constantly writing to their output pins. When you re-net, the new memory location gets updated on the very next run of the thread. In this case, the rawcounts variable might only get updated when a count occurs, so nothing happens until you turn the wheel. Or maybe it is being updated all the time, but the driver reads the value, increments (or decrements) it, and writes it back. In either case, the value from the signal (which always starts as zero) remains until you turn the wheel. > The example above was to check whether it was a bldc bug, and conv_s32 > was something I knew would have the right pin type. > > This is with 2.5.0_pre > > -- > atp > "Torque wrenches are for the obedience of fools and the guidance of wise > men" > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2dcopy1 > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > -- John Kasunich jmkasun...@fastmail.fm ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
