mb2hal sets up float pins. Can this be fixed?

I have downloaded the source code and can see where to change the data types. It looks like functions were added after the ini/how-to/manual was written and those are the ones with the floats.

Looks like the mb2hal executable is in /usr/bin with no extension displayed on the filename

The instructions for compiling this stuff is in the docs on LinuxCNC.org, so I'll need to do some homework on that and see if I can get the mb2hal fixed up.

Mb2hal is working fine now with a few workarounds, and I have to finish porting the device to LinuxCNC. Then I can play with GladeVCP and fixing the Modbus.

Guidance, of course would be greatly appreciated!

To Andy and everyone:

THANKS! I am an old hand at modifying MACH3 and MACH4 so I very much appreciate actually getting answers on a forum and being able to move forward thru whatever issues are blocking the road. Quite a contrast to the 'beg and wait' cycle that defines the 'MACH experience.'

It is my position at this point that LinuxCNC is the logical 'next step' up from MACH3, and this forum contributes to that opinion.

seb_kuzminsky wrote:

Which document are you referring to? As far as I know, mb2hal is completely undocumented, unfortunately.

The mb2hal source is in src/hal/user_comps/mb2hal, in our git repo.

Looking at the mb2hal code, it seems like it's creating both float and s32 pins (unfortunately named "int") for some registers, and just float pins for other registers.

I agree, it seems like it should be easy to support both float and s32 and/or u32 pins for all registers. I'd be happy to help you develop and merge a patch for this.

Sebastian,

the issue I was having with Python is resolved so I have downloaded the Git developer stuff as suggested by Big John. I've thus far only had time for a 'drive by' perusal, but I see your name in there, so I would very much appreciate the opportunity to be 'mentored' by you in fixing the mb2hal.

I am an engineer and not a programmer, but I do know my way around C enough to get stuff done and I have experience with Modbus and am familiar with the spec. I have modified and added to existing Modbus libraries for Atmel processors (Arduino) to effect compatibility with the new DUE board when it was released.

Also, for my current porting project, I made a more-or-less hacked version of my modified Atmel Modbus library to allow Coils to be exchanged between the Arduino and LinuxCNC, which are otherwise incompatible.

Goes without saying at this point that I know pretty much zip about Linux/LinuxCNC and the 'contribution' process for GNU stuff.

Certainly, you would be the better choice as lead on the programming end. I can help with the Modbus spec stuff and take out the garbage or whatever else you assign.

So, for starters, I do not see any purpose for having floating point or signed 32 bit numbers in a plain 16 bit register, and I *think* the signed data type is killing the ability to send negative numbers as they get 'converted' on the LinuxCNC side.

There would be some uber convenient features that could be added down the road to reflect modern usage of Modbus, like disassembling actual floats into 16 bit registers, and bit packing ( I don't like bit packing, but it is common).

The first thing to do is change the registers (pins, in LinuxCNC speak) to u32. I have very limited availability, but let me know what you want me to do and I'll try to get it schedules.

and . . .THANKS!

andypugh wrote:

Simpson36 wrote:

So, for starters, I do not see any purpose for having floating point or signed 32 bit numbers in a plain 16 bit register, and I *think* the signed data type is killing the ability to send negative numbers as they get 'converted' on the LinuxCNC side.

This is probably intended as a convenience ting for HAL integration. For example the inputs and outputs of G-code to HAL are float type, even if the data is integer. Having the mb2hal pins duplicated allows them to be connected in HAL without several type conversions.

I have all of the source code now, but have only looked at mb2hal and something jumped right out at me:

hal_float_t **float_value;
hal_s32_t **int_value;
//hal_float_t *scale; //not yet implemented
//hal_float_t *offset; //not yet implemented

notice the 'not yet implemented' comment. It would appear that, as you pointed out, the author had in mind to provide some built in conversions but has not gotten around to implementing them.

This would be great IF the conversions were completed and built in, but is quite a hindrance otherwise because you are then prevented from doing the proper conversion. Its a problem when you want to convert an u32 to a FLOAT, but the conversion won't take it because the data type is an s32. Sticking a raw 16 bit value into an s32 or FLOAT data type with no conversion is essentially what is happening, unless I am missing something.

In any case, since per Modbus spec, no assumption can be made about the actual value of the register coming from an unknown source, the only safe option is to assign it u32 and let the user convert as needed for a known reason.

By way of example, pretty much all coords are floating point and if you want to xfer these over Modbus (as my device does in order to calculate SFM), you need to get this guy into 16bit registers. Say you need to send -12.7654 . . . oops. There are a number of ways to accomplish this, but say you want to strip off the integer portion, add or subtract that from the float (depending on the sign) and then multiply the remainder x 10000. Stuff the integer part into one register and the 'fractional component', which is also now an integer, into another 16 bit register. How would you re-assemble that if both values are now s32 or FLOAT data type? For starters, where is the sign coming from? What if you want an absolute value? What if you don't?

Its a problem.

While we're on this topic, if would be really useful if you expanded your set of conversions with routines to break up floats or 32 bit or 64 bit numbers into 16 bit chunks and then put them back together.

andypugh wrote:

Simpson36 wrote:

While we're on this topic, if would be really useful if you expanded your set of conversions with routines to break up floats or 32 bit or 64 bit numbers into 16 bit chunks and then put them back together.

You might find this interesting, from the mailing list:
sourceforge.net/p/emc/mailman/message/34671204/

Andy, yes this is pretty much what I was taking about. Two points that I made previously are reiterated in this conversation. 1) that the more accuracy you need, the more registers you need and the more complicated the process gets. And 2) that unless the method by which the floats were split up is KNOWN to duplicated at BOTH ends of the xfer, AND which registers hold which parts of the float, then there is no reliable way to reassemble the float. There is no 'standard' way of doing this, so hard coding a specific method is asking for trouble, in my view.

As to what I would want, there are two opportunities here, to FIX and then IMPROVE.

The FIX that is needed is to have all registers as u32. That's it, pretty much.

In every other way, the mb2hal seems to be excellent. Probably the best I've seen functionally, albeit not the fastest, and I've used a lot of different ones. I have work around in place for all the quirks so I'm good to go and would have to go back and 'unhack' everything if mb2hal got fixed now. Apparently not many people use Modbus with LinuxCNC, but the register thing its a bit of a glaring boo-boo and should be fixed, I think. An offer was made to fix it and I accepted, but that hasn't gone anywhere so far.

Done deal.

Right now I do not have time to go back an 'unhack' all of the LinuxCNC stuff that I just finished, so testing this fixed Modbus will have to wait.