mb2hal sets up float pins. Can this be fixed?
02 Jan 2016 01:33 - 02 Jan 2016 01:40 #67677
by Simpson36
Replied by Simpson36 on topic 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!
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!
![:kiss: :kiss:](/media/kunena/emoticons/kissing.png)
Last edit: 02 Jan 2016 01:40 by Simpson36. Reason: found compile docs on LinuxCNC.org
Please Log in or Create an account to join the conversation.
02 Jan 2016 01:41 #67678
by andypugh
You will end up with a complete separate version of LinuxCNC on your computer, with the modifications. This is probably what you want, at first.
You will need to use the command line.
Once you have cloned the git repository, you should have a linuxcnc-dev folder containing all the source code. If you don't then things have gone wrong already.
You may need some extra compiler, you can get these from the synaptic package manager: to start with, get "build-essential" and "linuxcnc-dev"
You only need to configure the name and email part if you intend to submit changes to the LinuxCNC project. But you might as well. You are exactly where I was a few years ago, I didn't know any C, but there was something about LinuxCNC which wasn't how I wanted it...
So:
cd linuxcnc-dev/src
./configure
./autogen.sh
make
Will build LinuxCNC from source. Except it probably won't, in practice. You probably need to install autoconf, and other things.
This is where you may want to step away from the Synaptic GUI, and start using "sudo apt-get install package-name", which actually does exactly the same as the Synaptic GUI.
There are a lot of other packages you need to get to build LinuxCNC, but because I already have them, I can't get that list.
There is one way to get a list here, section 2.4: wiki.linuxcnc.org/cgi-bin/wiki.pl?Instal...g_build_dependencies
The list isn't something that you can just sudo apt-get install, but it nearly is. You can basically copy-paste the list, run back through it, taking out comments about versions and taking out one option where there is an either/or option.
See how far you get, then tell us what the error message is. This will be an iterative process, don't worry about that.
Replied by andypugh on topic mb2hal sets up float pins. Can this be fixed?
could someone provide the steps needed to get from edited code to working module?
You will end up with a complete separate version of LinuxCNC on your computer, with the modifications. This is probably what you want, at first.
You will need to use the command line.
Once you have cloned the git repository, you should have a linuxcnc-dev folder containing all the source code. If you don't then things have gone wrong already.
You may need some extra compiler, you can get these from the synaptic package manager: to start with, get "build-essential" and "linuxcnc-dev"
You only need to configure the name and email part if you intend to submit changes to the LinuxCNC project. But you might as well. You are exactly where I was a few years ago, I didn't know any C, but there was something about LinuxCNC which wasn't how I wanted it...
So:
cd linuxcnc-dev/src
./configure
./autogen.sh
make
Will build LinuxCNC from source. Except it probably won't, in practice. You probably need to install autoconf, and other things.
This is where you may want to step away from the Synaptic GUI, and start using "sudo apt-get install package-name", which actually does exactly the same as the Synaptic GUI.
There are a lot of other packages you need to get to build LinuxCNC, but because I already have them, I can't get that list.
There is one way to get a list here, section 2.4: wiki.linuxcnc.org/cgi-bin/wiki.pl?Instal...g_build_dependencies
The list isn't something that you can just sudo apt-get install, but it nearly is. You can basically copy-paste the list, run back through it, taking out comments about versions and taking out one option where there is an either/or option.
See how far you get, then tell us what the error message is. This will be an iterative process, don't worry about that.
The following user(s) said Thank You: Simpson36
Please Log in or Create an account to join the conversation.
02 Jan 2016 03:05 #67682
by Simpson36
Replied by Simpson36 on topic mb2hal sets up float pins. Can this be fixed?
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.
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.
Please Log in or Create an account to join the conversation.
02 Jan 2016 11:37 - 02 Jan 2016 11:38 #67697
by BigJohnT
Of course me an you know that the first terminal command depends on what he named the directory. I prefer a much shorter emc.
Adding to what Andy said the name and email are a local thing, your not signing up for anything. After installing git if you view hidden files and folders (an option on the file browser) and after you configure the global name and email in your home directory you will find a .config and in that a git with your name. If you omit the global which I do because LinuxCNC is not the only project on my computer then in the directory you cloned LinuxCNC to will have a .git directory which will have the name and email. What all this is for as Andy mentioned is if you want to contribute your work back to LinuxCNC you have to use a git patch which will contain your name and email to give you credit or blame as the case may be.
JT
Replied by BigJohnT on topic mb2hal sets up float pins. Can this be fixed?
So:
cd linuxcnc-dev/src
./configure
./autogen.sh
make
Of course me an you know that the first terminal command depends on what he named the directory. I prefer a much shorter emc.
Adding to what Andy said the name and email are a local thing, your not signing up for anything. After installing git if you view hidden files and folders (an option on the file browser) and after you configure the global name and email in your home directory you will find a .config and in that a git with your name. If you omit the global which I do because LinuxCNC is not the only project on my computer then in the directory you cloned LinuxCNC to will have a .git directory which will have the name and email. What all this is for as Andy mentioned is if you want to contribute your work back to LinuxCNC you have to use a git patch which will contain your name and email to give you credit or blame as the case may be.
JT
Last edit: 02 Jan 2016 11:38 by BigJohnT.
The following user(s) said Thank You: Simpson36
Please Log in or Create an account to join the conversation.
04 Jan 2016 19:25 - 04 Jan 2016 19:29 #67864
by Simpson36
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!
Replied by Simpson36 on topic mb2hal sets up float pins. Can this be fixed?
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!
Last edit: 04 Jan 2016 19:29 by Simpson36.
Please Log in or Create an account to join the conversation.
04 Jan 2016 20:26 #67872
by andypugh
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.
Replied by andypugh on topic mb2hal sets up float pins. Can this be fixed?
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.
Please Log in or Create an account to join the conversation.
04 Jan 2016 21:53 - 04 Jan 2016 22:12 #67880
by Simpson36
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.![:unsure: :unsure:](/media/kunena/emoticons/unsure.png)
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.
Replied by Simpson36 on topic mb2hal sets up float pins. Can this be fixed?
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.
![:unsure: :unsure:](/media/kunena/emoticons/unsure.png)
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.
Last edit: 04 Jan 2016 22:12 by Simpson36.
Please Log in or Create an account to join the conversation.
05 Jan 2016 13:01 #67920
by andypugh
You might find this interesting, from the mailing list:
sourceforge.net/p/emc/mailman/message/34671204/
How would you like mb2hal to work? Perhaps it could take a config string like the Hostmot2 SSI driver does, that specifies exactly what the bit positions are encoding?
linuxcnc.org/docs/2.7/html/man/man9/hostmot2.9.html#Synchronous Serial Interface (SSI)
Replied by andypugh on topic mb2hal sets up float pins. Can this be fixed?
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/
How would you like mb2hal to work? Perhaps it could take a config string like the Hostmot2 SSI driver does, that specifies exactly what the bit positions are encoding?
linuxcnc.org/docs/2.7/html/man/man9/hostmot2.9.html#Synchronous Serial Interface (SSI)
Please Log in or Create an account to join the conversation.
05 Jan 2016 19:47 - 05 Jan 2016 20:13 #67936
by Simpson36
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.
Replied by Simpson36 on topic mb2hal sets up float pins. Can this be fixed?
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.
Last edit: 05 Jan 2016 20:13 by Simpson36.
Please Log in or Create an account to join the conversation.
06 Jan 2016 18:37 #67977
by Simpson36
Replied by Simpson36 on topic mb2hal sets up float pins. Can this be fixed?
Please Log in or Create an account to join the conversation.
Time to create page: 0.190 seconds