Machsupport Forum
Mach Discussion => Mach4 General Discussion => Topic started by: simpson36 on May 06, 2014, 11:51:07 AM
-
Just wanted to get a thread started with Modbus in the title.
So far, I have not been able to get Modbus working. No help from the developers except to claim that Modbus works 100% and that there is no documentation available. I asked the developers for a brief explanation of the procedure, but did not gat an answer.
I can get MACH4 to connect with Serial and TPC, but there is no Modbus communication. I have searched the internet and the forum for any clues, conversation, documentation and have found no information at all.
Has anyone gotten Modbus running with MACH4?
-
Hey Simpson,
I had a spindle controlled by Modbus working a couple of versions back. I had some help though. I hope to get a chance to load the latest soon and can hopefully give a little more information. It worked for a bit but on the next power up I had no spindle control. I am not sure if it was something I did or a bug and I need to investigate a little more before commenting.
Brett
-
Hey Simpson,
I had a spindle controlled by Modbus working a couple of versions back. I had some help though. I hope to get a chance to load the latest soon and can hopefully give a little more information. It worked for a bit but on the next power up I had no spindle control. I am not sure if it was something I did or a bug and I need to investigate a little more before commenting.
Brett
Thanks Brett. Any info you can provide will be appreciated. I can't make any sense out of the config because I have no idea what data it is asking for. It wants a 'name' for example. No idea what it is looking for . . . ???
Even the most basic stuff would be useful. The developer claims Modbus is 'working 100%' but without some help, I'm dead in the water at this point.
-
I understand Simpson. I have attached a couple of screen shots I hope will help. Hopefully I will get to play with it some more later today.
Brett
-
We are trying to program Mach4 and fix bugs at this time. Doing tech support for modbus is to much of a distraction at this point. Let us get more core issues solved then we can see what we need to do to get your modbus working.
You should start by telling us what you are connecting too for hardware.
Thanks
Brian
-
Here is a Modbus BitOfWord Packing/Unpacking example using VB and a test screen, but could be adapted easily for M4 Lua,
to interface with PLCs etc.
http://www.machsupport.com/forum/index.php/topic,27165.msg191745.html#msg191745
-
The M4 modbus uses the newer Modicon table/register convention. Not the hex addressing that Mach3 used. There tables in the modbus spec that pertain to functions that operate on them. Modbus devices usually give the addresses in either hex addresses or the table/register format. And sometimes they will give both. Also, sometimes they prefix the addresses a bit differently.
Some do the T:RRRRR format where T is the modbus table and RRRRR is the base 1 register.
Others do a TRRRR format where an address may look like 40001. This is really table 4, register 1.
IMPORTANT: Addresses are base 0 and registers are base 1. The M4 modbus uses registers.
If the device documentation gives the old hex addressing format, convert the hex number to decimal and then add 1 (base 1 remember!). If the address is given in decimal, simply add 1.
Attached is a document that you may find useful.
Also, here is a good page that explains a lot. http://www.csimn.com/CSI_pages/Modbus101.html (http://www.csimn.com/CSI_pages/Modbus101.html)
Steve
-
This is the one I usually see in VFDs, and other industrial MB devices.
Others do a TRRRR format where an address may look like 40001. This is really table 4, register 1.
Thanks for the heads up Steve!
Scott
-
We are trying to program Mach4 and fix bugs at this time. Doing tech support for modbus is to much of a distraction at this point. Let us get more core issues solved then we can see what we need to do to get your modbus working.
You should start by telling us what you are connecting too for hardware.
Thanks
Brian
You can't train somebody in Modbus on this forum. And that is not the focus. I get that.
However, I did not ask for tech support on Modbus per se. I have had Modbus working with MACH3 for a couple of years now. I am familiar with Modbus and since Modbus is '100% working' in MACH4 Demo, I am willing to spend some time on MACH4 Modbus and report back my findings.
What I need is just a brief explanation of how Modus is implemented specifically in MACH4. Really I don't think it would take more than 15 minutes for describe what data the config screens are looking for. 'Name' can be interpreted a million ways.
All I need (I think) are the following answers and I *should* be off and running
1) What data are the config screens looking for? 'Name' of what?
2) How do you read a register in MACH4
3) How do you write a register in MACH4
That's it, I think. MACH3 had brains and they are gone. What replaces them. Scripts I would imagine. Fine, so how do you read and write the registers with a script? I have the hardware talking to MACH4. I just have no idea how to move the data. These are all MACH4 specific questions.
-
The M4 modbus uses the newer Modicon table/register convention. Not the hex addressing that Mach3 used. There tables in the modbus spec that pertain to functions that operate on them. Modbus devices usually give the addresses in either hex addresses or the table/register format. And sometimes they will give both. Also, sometimes they prefix the addresses a bit differently.
Some do the T:RRRRR format where T is the modbus table and RRRRR is the base 1 register.
Others do a TRRRR format where an address may look like 40001. This is really table 4, register 1.
IMPORTANT: Addresses are base 0 and registers are base 1. The M4 modbus uses registers.
If the device documentation gives the old hex addressing format, convert the hex number to decimal and then add 1 (base 1 remember!). If the address is given in decimal, simply add 1.
Attached is a document that you may find useful.
Also, here is a good page that explains a lot. http://www.csimn.com/CSI_pages/Modbus101.html (http://www.csimn.com/CSI_pages/Modbus101.html)
Steve
Thank you. This may explain why my Modbus only sees a constant zero function coming from MACH4. It should be relatively simple to make this change in the Modbus code. I'll tinker with that.
I am not asking for Modbus 101. I just need to know basic MACH4 stuff like config the plugin and how to read/write a register.
-
I understand Simpson. I have attached a couple of screen shots I hope will help. Hopefully I will get to play with it some more later today.
Brett
This is helpful, thanks. What is mbi1? do you make that up or is it a fixed system var? If you make it up, where is that done? If it is a system var, is there a list of them somewhere?
-
The name is what you would like to name the register.. In Mach4 you refer to the registers by name not by number!
The rest of it is:
Slave ID
Register (we have all the tables so sometimes you need to drop the first number.. for example I am working on a Mitsubishi drive now and I had to remove the 40000 because we know it should be in table 4.
Here are some examples of how I read and write:
Function from my RB1 to jog the head up by setting the HeadJogDir and HeadJogOn:
function HeadUp()
local inst= mc.mcGetInstance();
--Get the hReg handle of the modbus analog register
local HeadUp = mc.mcRegGetHandle(inst, "modbus0/HeadJogDir");
local HeadOn = mc.mcRegGetHandle(inst, "modbus0/HeadJogOn");
if (HeadUp ~= 0 and HeadOn ~= 0) then
mc.mcRegSetValue(HeadUp, 0);
mc.mcRegSetValue(HeadOn, 1);
end
end
Reading the Hz from the inverter from the Hz register:
local inst= mc.mcGetInstance();
local Hz = 0;
local HzReg = mc.mcRegGetHandle(inst, "modbus0/Hz");
if (HzReg ~= 0) then
Hz = mc.mcRegGetValue(HzReg);
end
You can also set it to be an input or an output on a register.. The register types are important.. you need to select the correct type (this is a modbus standard)
Hope that helps..
Brian
-
OK Thanks everyone. :-* I have a few nuggets to chew on now.
First I will need to change the comm method per Steve's post.
Then create some vars per Brett's post.
Then try to read and right to them per Brian's post.
That should keep me busy for a while.
-
OK Thanks everyone. :-* I have a few nuggets to chew on now.
O gosh... What flavor? I if they are brown with yellow spots, if so I can help you. Don't use them and DON'T chew them!
-
Getting 'Illegal argument error' in Mach4 Modbus diagnostic.
I do not see this error in any of the Modbus docs.
What is an 'argument'
-
What are you talking to for a device?
-
Hi Simpson
What device are you trying to connect to Modbus?
If you post a little more info I can try and help :)
I have 2 Allen Bradley Micrologix 1200 PLC's connect via 2 x RS232 connections
48 inputs 40 outputs
Illya
-
An Illegal argument error means that the argument to the modbus function is out of range. For example, each table can have 65535 registers but you put in 70001 by mistake. That would give an illegal argument error.
Or,
Say your device docs give a register number for the Control and Status Register of 40010. If you entered that for your modbus register in the config, you would get a illegal argument error. Because 40010 really means table 4 (holding registers, register 10). So entering 10 for the register is correct.
Also, if you enter a register number that your device does not have, then you will get that error.
It is important to note that the modbus plugin uses the Modicon convention for registers. Your device may give an address like "holding register 0". That is NOT the Modicon convention. So you must add one to the address to get the correct register, 1 in this case.
In the next update, I have added bit packing for register reads and writes. I thought it was in the plugin that you guys had but it was not. Somehow I botched the update and lost that functionality. Anyway, the next update will include bit packing and also fixes the RS485 enable stickiness.
Hopefully I can get time to do some example docs for modbus in the near future. But in the mean time, have a look at this modbus device simulator: http://www.plcsimulator.org/ (http://www.plcsimulator.org/). It is a really neat little program that emulates a TCP modbus device. You simply run the program and then configure the modbus plugin to connect to 127.0.0.1, port 502. You can then experiment with the different features of the modbus plugin and get the feel for how it works.
Steve
-
Thanks for the replies. It is good to know someone has it working.
I'll attempt to answer and also speculate on what I think might be happening.
1) Hardware: my 4th axis motor controller and also the ATC controller use Arduino MEGA development boards. These have an AtMEL processor and run C code (or Arduino's variant). These connect to the PC via USB and use a USB-> Serial chip and the appropriate driver to emulate a COM port at the PC side. They can be connected to a TTL-> RS232 converter and comm thru the actual physical serial port as well, but I have been using the virtual COM with MACH3 for a couple of years without issue.
2) Software: all of the Modbus functions are done by the AtMEL processor. The Modbus code is pubic and needed only some minor tweaking to work with MACH3. Options for MACH4 are to modify the code to use the structure described by Steve -or- there are also version of the public code that adhere to Modicon.
Problem:
I have a question about something Steve posted and I will ask about that separately, but the problem seems to be that MACH4 is not polling the slave. The reason I say this is that the board has indicators on the TX/RX lines and when I hook up to MACH3, I see the polling taking place because the LEDs are flashing. In the MACH3 'diag' moving the speed slider changes the flash rate and the correct (changing) test data is being read from the Processor.
MACH4 behavior:
The device is recognized and MACH4 reports 'Modbus0 OK' and displays a polling frequency. However, the LED on the board will flash once when exiting the config, but there is no continued flashing which indicates that MACH4 is not polling the device. I thought this might be an incompatibility with the virtual COM so I connected via TCP and the behavior is the same.
What is interesting is that MACH4 seems to think it is talking to the Modbus, based on it reporting 'Modbus OK' and posting a frequency. However, the board is not indicating that it is receiving anything on RX.
What is confusing to me is that MACH4 seems to definitely think it is talking to something, but there is silence on the other side.
My BAD: I am transitioning to a newer and much faster processor on the Arduino DUE board so I have a numch of those available to mess with. The only MEGA board I have in-house is running my 4th axis, so I can't pull that one out to play with. The newer DUE board works differently, has different libraries and the serial hardware on the board is different. I had to change the code for the DUO but it works fine with MACH3, however, it is still something of an unknown, so I have ordered a MEGA board to test with as I am much more familiar with that device. Hopefully it will be here today.
-
Hi Simpson
What device are you trying to connect to Modbus?
If you post a little more info I can try and help :)
I have 2 Allen Bradley Micrologix 1200 PLC's connect via 2 x RS232 connections
48 inputs 40 outputs
Illya
Thanks for the reply. If I could use a PLC, it would be Miller Time! It sounds like you are going in thru the RS232 Hardware. I can do that, but have not tried that yet. I am going thru a virtual COM port for the serial interface. This works fine with MACH3 and I thought it might be the problem with MACH4, so I went in thru TCP and the behavior did not change. I can also go in thru the physical RS232 port, but I'd just need to throw together a test rig and I have decided to back up a notch and work with a processor that I am more familiar with and eliminate an 'unknown' from the mix. Hopefully will be here today.
-
An Illegal argument error means that the argument to the modbus function is out of range. For example, each table can have 65535 registers but you put in 70001 by mistake. That would give an illegal argument error.
First, thanks for taking the time to put together this reply. I know you are very busy.
Second, I have a connection to MACH4, but I don't think any data is moving. MACH4 thinks it is talking to something, but there is nothing actually coming to the device. So I need to figure that out as a first step, I think.
Say your device docs give a register number for the Control and Status Register of 40010. If you entered that for your modbus register in the config, you would get a illegal argument error. Because 40010 really means table 4 (holding registers, register 10). So entering 10 for the register is correct.
Also, if you enter a register number that your device does not have, then you will get that error.
There is an entry for the number of registers, but I did not see anywhere to enter a register number in the config.
I think I must have missed something along the way. It was my impression that you just made up names for the registers.
Where do you enter register numbers in the config?
Hopefully I can get time to do some example docs for modbus in the near future. But in the mean time, have a look at this modbus device simulator: http://www.plcsimulator.org/ (http://www.plcsimulator.org/). It is a really neat little program that emulates a TCP modbus device. You simply run the program and then configure the modbus plugin to connect to 127.0.0.1, port 502. You can then experiment with the different features of the modbus plugin and get the feel for how it works.
Excellent. I'll take a peek. My focus is to see how to get data in and out of MACH4 thru its Modbus implementation so that I can plan my port and be thinking about how to utilize the new methods imposed by the MACH4 Modbus structure. If a simulator provides that, I'd be a happy camper and could work out the physical comm issues later on.
[/quote]
-
Hi Simpson
What device are you trying to connect to Modbus?
If you post a little more info I can try and help :)
I have 2 Allen Bradley Micrologix 1200 PLC's connect via 2 x RS232 connections
48 inputs 40 outputs
Illya
Sorry, I neglected to confirm that you are talking about MACH4.
You have the A/B's connected to MACH4 Modbus, is that correct?
-
Steve
These are the screen shots of the setup for my modbus using a AB PLC. :)
Illya
-
I did get the Modbus simulator to communicate and show life.
-
Steve
These are the screen shots of the setup for my modbus using a AB PLC. :)
Illya
This is odd. The 485 box is permanently checked on the version I have. I was thinking that might be the issue. Like somebody was waiting for an RTS or CTS or something like that. A deadly embrace kind of thing.
You have three Modbus setups. Is that for your multiple PLC's?
-
screen shot from the machine computer Modbus works well on it
-
No I only have two PLC's running. The post with three screen shots was from the notebook which I use to play around with the setup.
-
This is odd. The 485 box is permanently checked on the version I have. I was thinking that might be the issue. Like somebody was waiting for an RTS or CTS or something like that. A deadly embrace kind of thing.
[/quote]
Yes the tick does show up on mine as well. It seems to come up after you setup and saved the modbus device.It has not had an effect on mine.
-
Hopefully I can get time to do some example docs for modbus in the near future. But in the mean time, have a look at this modbus device simulator: http://www.plcsimulator.org/ (http://www.plcsimulator.org/). It is a really neat little program that emulates a TCP modbus device. You simply run the program and then configure the modbus plugin to connect to 127.0.0.1, port 502. You can then experiment with the different features of the modbus plugin and get the feel for how it works.
I ran the simulator and it has confirmed my suspicion. MACH4 Modbus is not communicating. If I use the sim with MACH3, I get a continuous series of polls from MACH3. With MACH4 the sim status window says connected and then just sits there with no more incoming data until it finally closes the port due to lack of activity.
Disable the firewall and antivirus, no difference.
Is there any setting in MACH4 that would cause the Modbus to not communicate?
This is Win7 Pro 64 Bit on all Intel Hardware. I can try it on a different machine and see if that makes any difference.
-
Success!
I moved both the MACH4 Demo and the sim to a different computer running Win7 Pro 32 Bit (which I should have done before now, :-[) and Modbus connected right away and is working.
MACH4 does not like something about my development system. Which is not so surprising . . I hate it myself sometimes :D
So now I can eval MACH4 Modbus anyway. I will see if by chance my processors will connect to MACH4 Modbus on the other computer. Anybody need and Arduino MEGA?
-
Wow... I have Win7-64 and I have no issue. It must be something on your machine. Modbus is not doing anything special with TCP. It is just a connection like any TCP app would make. Good luck figuring that one out!
For a bit more explanation:
A "connection" in the plugin is a connection to a device. So you would have a connection to each PLC or VFD. Each connection can use TCP or serial but not both.
Then, for each connection, you can have up to 100 functions defined. The functions require a starting register. The functions that read/rite multiple register all for a count to be added as well. When these functions are created, they create Mach registers or I/O, depending on the type of the modbus function. Theses are modbus resources. You must name these. The names will show in the Mach input and output signals mapping for I/O or, for registers, be available for the script environment.
The RS485 check box currently does nothing in the plugin that you have. I have tied it in for the next update.
Steve
-
Wow... I have Win7-64 and I have no issue. It must be something on your machine. Modbus is not doing anything special with TCP. It is just a connection like any TCP app would make. Good luck figuring that one out!
Ready for this? Run as Administrator and it started working on Win7 Pro 64 . . . go figure.
Edit: working to my device, that is. I have not revisited the sim on this machine yet.
Edit #2: Sim works also . . .
For a bit more explanation:
A "connection" in the plugin is a connection to a device. So you would have a connection to each PLC or VFD. Each connection can use TCP or serial but not both.
Then, for each connection, you can have up to 100 functions defined. The functions require a starting register. The functions that read/rite multiple register all for a count to be added as well. When these functions are created, they create Mach registers or I/O, depending on the type of the modbus function. Theses are modbus resources. You must name these. The names will show in the Mach input and output signals mapping for I/O or, for registers, be available for the script environment.
The RS485 check box currently does nothing in the plugin that you have. I have tied it in for the next update.
Thanks, I figured most of that stuff out by poking around. I also discovered that you cannot use registers to toggle binary I/O. I used the sim for that because my code only uses 'holders' at this point.
Also I have an Arduino DUE talking to MACH4 to write and read back a single holding register I/O. I'm sure the reason the DUE is working is because the new MEGA board arrived today . . ::)
I'll have to clean up the code for the Arduino DUE board (about 5x faster than the previous MEGA and cheaper to boot.), make an RTU and TCP version and add coils and so on, but I think I'm good to go for now. I have all of these posts printed out and in my 'manual' for reference. I will add to that and post anything particularly interesting. Looking forward to seeing what MACH4 has to offer to my applications.
Oh well, a huge THANK YOU to EVERYONE who contributed to getting me out of the dead calm. :D
-
Update and one question.
Update:
I've added coils and have the faster DUE board taking to MACH4 thru TCP reading and writing coils and 'holders'. All functions are working except 16 and I *think* I know what the problem is there. Buttons on screen are connected to coils and the processor is triggering inputs by sending coils. DRO's are displaying register data generated by the processor board and so on.
Observations:
MACH4 locks up frequently when closing the plug-in config screen. Usually when something 'illegal' is entered into the config.
MACH4 sometimes leaves a process running and will not start again until the process is killed with the task manager.
Only one time a plug-in config change wiped out the config. All that was left was the 'connection'. I found the backups and it was a quick fix. Just FYI
Have not tried scripting to/from Modbus yet and I'm out of time for this round.
Question:
How does one write to a single register other than #1? I cannot find a way to do that.
It seems there should be a way to create a function that write only 'holding register #4.
Thanks!
-
I've noticed using the simulation program that it only updates in real time for the first 16 outputs, if I leave the I/O coil Outputs screen and then come back to it then the outputs are correct, just wont scan for anything above 16, so not sure if that is a Mach4 issue or the simulation program.
-
The other issue I find is that I can only add 0 thru 31 outputs (mbo 0 thru 31)
on adding and using mbo32 it turns on address 2 in the simulation modbus Coil outputs
Nothing else can be added above 32 outputs (modbus configure limits me to 32 working outputs)
-
Comments:
1) config does not keep input/register selection if done with other changes. Must go back in afterward and set just the input/reg selection separately.
2) No convenient way found to stream data TO Modbus registers using the new screen editor.
i.e. cannot set up slider with data streaming going to a Modbus register
cannot set up a DRO with data echo to a Modbus register
3) no way found to write a selected single register - defaults to reg1 and not configurable - essentially useless
4) on Startup MACH checks Modbus function before screens are up. If there is a Modbus problem - Mach4 does not start - no message.
5) Mach4 frequently locks up exiting Modbus config screen. -or-
Mach4 continues to run, but Modbus Diag and Reg Diag inoperative.
Once this happens, MACHG4 GUI process must be killed with Task Manager before MACH4 can start up.
-
1) What config? Modbus or Mach?
2) Use the PLC script and scr.* API.
3) I'm not getting this one. Can you explain what you are wanting to do?
4) Can you provide and example? With say the Mod_RSSim modbus simulator? I can set up connections to the simulator, not run the simulator (like the PLC is off) and it works fine.
5) I have never seen this! I will try and find it.
BTW, some of the bug stuff needs to be posted in the bugs thread. That way we can track it.
Steve
-
1) What config? Modbus or Mach?
Modbus . . increase regs count, enter data ; type, name, descriptions, exit. Close MACH4, Reopen MACH4, go to Modbus Config for the function you kust edited and all types have defaulted to input. Change them to registers again, exit, and this time they stick.
2) Use the PLC script and scr.* API
OK, will do. Note I said no CONVINIENET way. Would be nice to have a third data rounting check box to stream data to a Modbus reg. . . . . I'm just being lazy
3) I'm not getting [selected single register ] this one. Can you explain what you are wanting to do?
Want to Write a single register OTHER than #1. No way to do it. You mentioned earlier about putting addresses into the config correctly (i.e. 1 and not 40001), but I have not found any place to enter addresses at all.
4) Can you provide and example? With say the Mod_RSSim modbus simulator? I can set up connections to the simulator, not run the simulator (like the PLC is off) and it works fine.
MACH4 appears to test the Modbus before startup (before screen loading anyway). I can see the polling MACH4 is doing. If the Modbus is healthy, the test takes a few seconds and MACH4 starts. If the Modbus is OFF (as in your example) MACH4 logically would not be able to test, so it just starts. However, if Modbus is Active but is sick or if the user just configures it incorrectly, MACH hangs trying to get a good response from Modbus. The only way to recover (that I found) was to revert to an earlier backup .ini
My suggestion is that if Modbus is active, have MACH4 start and then test the Modbus. If there is a problem, MACH4 should provide and error message to theuser and ignore Modbus so that the user aq) knows what the problem is and B) can re-configure to correct an error without knowing how to retrieve backup .ini and so on.
I think it would be beneficial to both myself and Artsoft from a SUPPORT standpoint. People will be calling in sayng MACH4 won't start and there will be no indication why.
5) I have never seen this! I will try and find it.
I suspect there are not a lot of folks working with the Modbus at this point . . or ever for that matter.
#3 is a problem. The rest are minor inconveniences and #5 is a potential support problem so those are just FYI.
Note that these issues are happening on my development system which MACH4 may not be happy with for some reason, so some of this stuff may be local to my desk . I'm just recording it via post when I encounter it.
BTW, some of the bug stuff needs to be posted in the bugs thread. That way we can track it.
No problem. In fact, I just echoed some stuff to the 'new features' thread from here. I'm just not sure what is a bug and what is operator error at this point. If it turns out the problem is not my own ignorance, then certainly I'll repost in the bug section so that it will get collected.
Thanks very much for this response.. I have all Modbus functions working now via TCP (except item #3 here (single reg write), which works, but is stuck at reg1).
Steve
[/quote]
-
Here is a screen shot of where to put the register number. It is the highlighted text field. If you need to read multiple consecutive registers, then use a function that reads multiple regs. Input the starting register in the highlighted field and then enter the number of regs to read in the count field. The count includes the register defined in the register field.
If you don't need consecutive registers, then do separate single register functions.
Steve
-
Here is a screen shot of where to put the register number. It is the highlighted text field.
Another mystery solved. 8) I thought this was the 'Modbus address'. i.e. the companion to the 'Slave Address' since there can be multiple Modbus ('connections') and multiple Slaves. It can be confusing that in MACH4 speak, for example 'Functions' are numbered sequentially regardless of which actual Modbus function number is contained in them. I assumed because of the title of the field, that the 'Modbus Address' was the 'connection' number and worked the same. ex.: if you have configured multiple 'connections' of MACH4 Modbus 0 thru 5 and then say the 'connections' Modbus2 and Modbus4 pointed to the same physical device which was physical Device at Modbus Address 1, then the field labeled Modbus Address would be used to point to the correct device. This seems to be how the Slave Address works.
In any case, it never occurred to me that 'Modbus address' was the Register Number.
SUGGESTION;
This was my bad and when the documentation catches up, it might be clarified. However, entering the Register Number in field labeled Modbus Address is not intuitive and might be another support hotspot.
Since MACH4 uses Register NUMBERS instead of ADDRESSES, it might be a good idea to make MACH4 Modbus labeling consistent with that new method and also to highlight the change for upgraders from MACH3 to MACH4. I also think it would be preferable to use a term other than 'Function' because it means something different in the Modbus and MACH4 vernaculars. 'Process' or 'Group' or 'Action' pretty much anything other than 'Function' would be better. Perhaps instead of 'modbus0, modbus1, etc', MACH4 could use the term 'Device0, Device1' or again, any term that does not create a dual definition. MACH4 Modbus vs the Modbus spec. MACH4 Function vs Modbus Function and so on. That's just a suggestion. I'm thrilled that the feature is there and that I just did not know how to get to it.
FWIW, there was a span of about 15 years where I was responsible for supporting CAD software and if you throw out software bugs, then confusing terminology was the primary driver of support calls. Don't even mention Adobe . . . software written by counter-intelligence agents. ::)
If you need to read multiple consecutive registers, then use a function that reads multiple regs. Input the starting register in the highlighted field and then enter the number of regs to read in the count field. The count includes the register defined in the register field.
BUG?
Write multiple register is the last function that I got working with MACH4 on my end. Your last post prompted me to tinker with different starting register numbers in the Write Multi Reg function and it uncovered an unusual behavior. The attacxhed screen shot shows that a Mach4 Modbus Function has been created to write two Holding Regs starting with #6. Both are 'Type' Register, yet only one shows up in the MACH reg Diagnostic window. I have not played with it enough to know if this is random or if it is limited to skipping the first reg in the sequence.
BUG or SFU? (Simpson Foul UP). If it turns out to be a bug, then I'll post it over in the appropriate section.
EDIT: hold off on this one . . it may be related to using duplicate reg names. MACH4 just dumped the whole Function on its own Went back into MACH4 and the Function is just gone. ???
I'll mess with this some more. Lookig more like an SFU at this point.
Thanks again for responding to my questions. Now that the 'mechanics' are all sorted out, I will move on to play with scripting.
-
Update on editing Register TYPE.
MACH4 will now not keep any CHANGES to the TYPE after the REG has been created.
It *seems* to me that I could go in and edit the TYPE, but that may have been on the first demo ver. . . -or- I dreamed it . . :-\
In any case, at this point, MACH4 will not retain Register TYPE changes. It allows the Edit without complaint, but the change is not saved.
Deleting the Function line (in MACH4 Modbus Config) and re-creating a new one with the same Reg names allows and saves the new Reg TYPE
This may be by design to prevent system corruption by changing TYPE after the reg has been used in a TYPE specific screen or macro, but it would be good to know if this behavior (not saving TYPE edits to existing regs) is intentional.
-
modbus reading registers from the simulator
how do to write to the simulator is the next challenge.
-
modbus reading registers from the simulator
how do to write to the simulator is the next challenge.
Anyone who just wants to test the data xfer follow this procedure:
Set up a function to write registers, (looks like you already have that). Make sure the TYPE is register.
Get the sim running and set to show the registers.
Get your Modbus diag window running, expand the function so you can see the register values.
Go back into MACH4 Diags -> Regfile -> Modbus + box
Double click on any Reg and you should get a Dialog box where you can enter a value.
Do so and click OK and the value should appear (rather quickly I might add) in the Modbus Reg as well as the Simulator.
I have not had a chance to play with the scripting yet.
-
:-X ty
cool... now to get the scripting to work
something worked kind of in my messing around
-
Graig,
You are adding two handles that sum to a number larger than a 16 bit register will take. The internal Mach register can store that number easily. But the 16 bit register in the PLC cannot. It also looks like the Rhr3 is also part of a read function. The internal Mach register will not get updated unless the value ON the PLC changes. Yet is it possible to SET the value internally from the Mach side. So if you wrote a number in the simulator register 40003, it would have changed the value in the Register Diagnostics window.
The correct way to do the register read is with two API calls.
local hRhr1 = mc.mcRegGetHandle(inst, "modbud0/Rhr1");
local valRhr1 = mc.mcRegGetValue(hRhr1);
local hRhr2 = mc.mcRegGetHandle(inst, "modbud0/Rhr2");
local valRhr2 = mc.mcRegGetValue(hRhr2);
local hRhr3 = mc.mcRegGetHandle(inst, "modbud0/Rhr3");
mc.mcRegSetValue(hRhr3, valRhr1 + valRhr2);
Rhr3 should == 24564 which is within the 16 bit range.
An enterprising LUA programmer can shorten the 2 API calls with something like this:
function ReadReg(regName)
local inst = mc.GetInstance();
local hReg = mc.mcRegGetHandle(inst, regname);
local val = mc.mcRegGetValue(hReg);
return(val);
end
function WriteReg(regName, val)
local inst = mc.GetInstance();
local hReg = mc.mcRegGetHandle(inst, regname);
mc.mcRegSetValue(hReg, val);
end
Those are hand written on-the-fly functions so they may not be totally correct. But put something like them in the Screen load script and you can access them from any screen/object script. This will make things a bit easier in the code like:
local valRhr1 = ReadReg("modbud0/Rhr1");
local valRhr2 = ReadReg("modbud0/Rhr2");
WriteReg("modbud0/Rhr3" valRhr1 + valRhr2);
Steve
-
Thanks Steve
I knew that, but a bad example gets more attention >:D
time to play and learn
thanks again
-
local inst= mc.mcGetInstance();
local hRhr1 = mc.mcRegGetHandle(inst, "modbud0/Rhr1");
local valRhr1 = mc.mcRegGetValue(hRhr1);
local hRhr2 = mc.mcRegGetHandle(inst, "modbud0/Rhr2");
local valRhr2 = mc.mcRegGetValue(hRhr2);
local hRhr3 = mc.mcRegGetHandle(inst, "modbud0/Rhr3");
mc.mcRegSetValue(hRhr3, valRhr1 + valRhr2);
function ReadReg(regName)
local hReg = mc.mcRegGetHandle(inst, regName);
local val = mc.mcRegGetValue(hReg);
return(val);
end
function WriteReg(regName, val)
local hReg = mc.mcRegGetHandle(inst, regName);
mc.mcRegSetValue(hReg, val);
end
valRhr1 = ReadReg("modbus0/Rhr1");
valRhr2 = ReadReg("modbus0/Rhr2");
WriteReg("modbus0/Wsr1", valRhr1 + valRhr2);
--works thanks
-
Graig,
The correct way to do the register read is with two API calls.
local hRhr1 = mc.mcRegGetHandle(inst, "modbud0/Rhr1");
local valRhr1 = mc.mcRegGetValue(hRhr1);
local hRhr2 = mc.mcRegGetHandle(inst, "modbud0/Rhr2");
local valRhr2 = mc.mcRegGetValue(hRhr2);
local hRhr3 = mc.mcRegGetHandle(inst, "modbud0/Rhr3");
mc.mcRegSetValue(hRhr3, valRhr1 + valRhr2);
A response to your post said this was working, but I don't see how. Note the spelling is modbuD which looks like a typo.
An enterprising LUA programmer can shorten the 2 API calls . . .
But put something like them in the Screen load script and you can access them from any screen/object script.
What is the file name of the 'Screen load script' ? The file that scrolls when you select 'LUA sciprt' from the Operator dropdown looks like the right file, but it is compiled and cannot be edited. I tried some tricks, but nothing worked.
local valRhr1 = ReadReg("modbud0/Rhr1");
local valRhr2 = ReadReg("modbud0/Rhr2");
WriteReg("modbud0/Rhr3" valRhr1 + valRhr2);
Is this just a 'cut and paste' typo, or should "modbud" be used?
Being unable to figure out how to add functions to the 'Screen load script', I tried making a macro. The macro runs in the debugger, but almost never from the MDI and never from within G-code.
Even more strange is that it does run on every MACH4 startup. I'm sure I have done something wrong, but I have tried a lot of stuff and no joy. Need a little help here. File name is m40. First and last line commented out because it won't run at all that way. Message boxes are for diagnostic purposes. It runs from the debugger and executes properly, reading and writing the regs as expected.
--function m40()
local inst
local hRhr1;
local valRhr1;
local hRhr2;
local valRhr2;
local hRhr3;
local valString;
wx.wxMessageBox("Start");
inst=mc.mcGetInstance();
hRhr1 = mc.mcRegGetHandle(inst, "modbus0/Hreg1");
valString = tostring(hRhr1);
wx.wxMessageBox(valString);
valRhr1 = mc.mcRegGetValue(hRhr1);
valString = tostring(valRhr1);
wx.wxMessageBox(valString);
hRhr2 = mc.mcRegGetHandle(inst, "modbus0/Hreg2");
valRhr2 = mc.mcRegGetValue(hRhr2);
valString = tostring(valRhr2);
wx.wxMessageBox(valString);
hRhr3 = mc.mcRegGetHandle(inst, "modbus0/Wreg3");
valString = tostring(valRhr2 + valRhr1);
wx.wxMessageBox(valString);
mc.mcRegSetValue(hRhr3, valRhr1 + valRhr2);
wx.wxMessageBox("Done");
--end
-
What is the file name of the 'Screen load script' ? The file that scrolls when you select 'LUA sciprt' from the Operator dropdown looks like the right file, but it is compiled and cannot be edited. I tried some tricks, but nothing worked.
Cliick on wxmach in the tree, then below on events.
Russ
-
I just focused on the functions and made sure it found my register values, pulled, computed and passed back the right value.
all done under a button I created to test.
I'm just adding the first and the second and putting the new value back in the first, basically an additive loop.
just to prove out how to do a modbus scripting feature.
now to figure out how to use the data and make bit wise decision.
found they did not really make a difference in my setup, so did not address them.
but going back, now that you reminded me of it, could be very useful. :)
if you change them to the correct modbus0 name, as you step thru the function you can see them pass the values
local hRhr1 = mc.mcRegGetHandle(inst, "modbus0/Rhr1");
local valRhr1 = mc.mcRegGetValue(hRhr1);
local hRhr2 = mc.mcRegGetHandle(inst, "modbus0/Rhr2");
local valRhr2 = mc.mcRegGetValue(hRhr2);
local hRhr3 = mc.mcRegGetHandle(inst, "modbus0/Rhr3");
mc.mcRegSetValue(hRhr3, valRhr1 + valRhr2);
far as a m40
you would have to put the script in a m40.mcs file
then call it as a mcode
remember that you have to restart Mach4 to compile the new m40.mcs file
everytime you edit it.
-
What is the file name of the 'Screen load script' ? The file that scrolls when you select 'LUA sciprt' from the Operator dropdown looks like the right file, but it is compiled and cannot be edited. I tried some tricks, but nothing worked.
Cliick on wxmach in the tree, then below on events.
Russ
Thanks. I'll give that a try!
-
if you change them to the correct modbus0 name, as you step thru the function you can see them pass the values
Thanks. I had a feeling it was just a typo. I though the term might be different on purpose to eliminate a conflict somewhere , but nothing is working for me either way, so I could not confirm.
far as a m40
you would have to put the script in a m40.mcs file
then call it as a mcode
Yes, it is an M40 macro. I tried it both source and compiled. It does work via the debugger, just really unpredictable from MIDI and never runs from G-code. Another mystery.
Incidentally, there is a compile choice on one of the drop downs in the editor, so you *,ight* not need to restart MACXH4 every time.
I did not know MACH4 compiled the macros at startup, but a glitch in that might explain why M40 runs every time MACH starts. That is really weird.
There is a possibility that these spooky problems have more to do with my Win7 Pro 64 bit machine than with MACH4. I will run this on my CNC computer which is less complicated and runs 32 bit Win 7 pro.
Thanks for the help.
-
If the macro script is not wrapped in a function, then that is what you will get.
This is what a macro should look like. Notice at the bottom it has code that detects the editor so that it will actually run the M40 function.
function m40()
inst=mc.mcGetInstance()
mc.mcCntlSetLastError(inst, 'I'm in M40!!!!')
end
if (mc.mcInEditor() == 1) then
m40()
end
Steve
-
I just created a m40.mcs and called it up with a mdi and It works for my address's
change address to suit your named ones.
function m40()
local inst= mc.mcGetInstance();
local hRhr1 = mc.mcRegGetHandle(inst, "modbus0/Rhr1");
local valRhr1 = mc.mcRegGetValue(hRhr1);
local hRhr2 = mc.mcRegGetHandle(inst, "modbus0/Rhr2");
local valRhr2 = mc.mcRegGetValue(hRhr2);
local hRhr3 = mc.mcRegGetHandle(inst, "modbus0/Rhr3");
mc.mcRegSetValue(hRhr3, valRhr1 + valRhr2);
function ReadReg(regName)
local hReg = mc.mcRegGetHandle(inst, regName);
local val = mc.mcRegGetValue(hReg);
return(val);
end
function WriteReg(regName, val)
local hReg = mc.mcRegGetHandle(inst, regName);
mc.mcRegSetValue(hReg, val);
end
valRhr1 = ReadReg("modbus0/Rhr1");
valRhr2 = ReadReg("modbus0/Rhr2");
WriteReg("modbus0/Wsr3", valRhr1 + valRhr2);
end
if (mc.mcInEditor() == 1) then -- as Steve said this works in the editor for debugging the m40 function only
m40()
end
-
[quote author=smurph link=topic=27158.msg192373#msg192373 date=1400088487]
If the macro script is not wrapped in a function, then that is what you will get.
if (mc.mcInEditor() == 1) then
m40()
end
My Macro was modeled after the existing M6 which does not have the editor detector at the bottom. I was blissfully unaware of the bit of the puzzle.
The macro was wrapped in a function, but would not run in the editor UNLESS it was unwrapped and stepped thru. Catch 22.
Now, with the 'In Editor' statements, I see that I can step thru AND it will also run.
I have your read and write functions added to the proper file (much thanks to Overloaded) but I am getting an error message when I try to use them in a macro. Something about a chunk.
So, again thanks to all for the help. The macro is running now and I'll tinker about with calling the functions and see f I can get something going with that rout or by attaching the calls to a button . . . which I do not know how to do either . . LOL!!
Anyway, one step at a time, it is coming together. Thanks to everyone for their patience.
-
Trying to call the new functions. Stepping thru the script and getting error message that indicates MACH4 is attempting to get the Registers off the computer's NIC address.
The script I am attempting to run and the added functions are shown below. The IP in the error msg is the computer.
The script is attached to a screen button. I have tried it wrapped and unwrapped. 22 was substituted for the added vars to eliminate one possible cause.
-
Is regName case sensitive ?
-
id say by the look of it, you cannot local inst mc.mcGetInstance() more than once in the same over all button script
the functions would have to be in the load script area and you call them from there
if they are in the same overall function you call it at the top once
please post as code this is a pita to follow
-
attempt to call global 'ReadReg' (a nil value)
I don't get why you cannot call a 'global' anything, but I've run out of things to try, so I post here FWIW.
My schedule s slammed and I probably won't find much time to indulge my new MACH4 addiction, but I wanted to take time to leave some initial comments on the 'MACH4 experience' since I suspect that's what they are looking for.
GENERAL COMMENTS:
As far as the 'global call' issue; while it is typically easier to maintain an application that is composed of centralized functions, but I find that developing under a 'mothership' can dictate different priorities. From a support standpoint, sometimes it is better to have all of the code for a particular action self contained as that isolates a problem and prevents my stuff from going south if a user modifies the screen script and messes something up, or tries out a new slick feature that comes in the form of a new screen script which of course would not have all of my routines. It might also prevent a bug injected in a new release from thrashing everything. The bottom line of all that is that it's not particularly important for my purposes that the 'global' function calls work perfectly. I probably will not use them unless they are contained in a separate file that would be immune to changes in the main screen script.
Certainly I do not know nearly enough about MACH4 to make a decision on that, but I think I have enough stuff working to evaluate the new methodology and perhaps come up with a plan for porting my stuff over. I have a bunch of new features to add also, but MACH3 is just too convoluted to be a good host for them. Lack if individually accessible registers prevented me from taking advantage of the much better Serial Plug-in structure. Broken Bit Wise operations, etc.
Kudos to the developers for making one structure for all of the Modbus interfaces in MACH4. The different setups for TCP vs Serial vs Serial plug-in are . . . . a challenge. I've only scratched the surface thus far, but it appears to me that MACH4 is going to be a far superior platform to develop under than MACH3.
It has been challenging to get stuff to work. I purchased a LUA programming guide, but that doesn't help with the MACH specific stuff. When the MACH4 docs catch up, I expect it will not be such a chore to figure out how to do stuff. I know this demo was not released with the intent of users hacking away at the Modbus, so I appreciate the responses from everyone, particularly from the developers.
OVERALL IMPRESSION:
I think the developers are creating a support nightmare for everyone with the confusing Modbus terminology and a support nightmare for themselves with the packaging of the commercial/industrial version, but neither of those directly effect me at this point, so my opinion, plus about six bucks, will get you a coffee drink at Starbucks.
Primarily, I build prototypes and therefor use the MDI a LOT so as I said previously, the Multi-Line MDI by itself easily justifies the $200 for MACH4 and I found that feature almost immediately. My focus here was to see what improvements had been made to the Modbus interface because that effects what can be developed on top of the new faster, mo' better core. The parts that I need to work, do work, and at first blush, it seems that the limitations have been moved from the software itself to the creativity and skill of the programmer, so that is a very good thing.
-
--i put this in the screen load script and I don't see any issues calling it from any place ::)
function ReadReg(regName)
local inst= mc.mcGetInstance();
mc.mcCntlSetLastError(0, 'ReadReg = ' .. tostring(ReadReg));
local hReg = mc.mcRegGetHandle(inst, regName);
local val = mc.mcRegGetValue(hReg);
return(val);
end
function WriteReg(regName, val)
local inst= mc.mcGetInstance();
mc.mcCntlSetLastError(0, 'WriteReg = ' .. tostring(WriteReg));
local hReg = mc.mcRegGetHandle(inst, regName);
mc.mcRegSetValue(hReg, val);
end
-
I recon not. ::)
Would have assumed it would be though.
Seems most thing are quite specific in this programming stuff.
Is this an exception ?
Thanks,
Russ
-
HIYA Russ, From what I can tell EVERYTHING in LUA is case sensitive and it adds to the complexity of programming it.
(;-) TP
-
That's what I assumed as well Tery.
I notice in Craig's example, they are all the same case wise.
Russ
-
write a script under a button and test by stepping thru it
CASE = "yes";
case = "no"
Case =1
CasE =2
a=a
you bet it is case sensitive
-
Thanks Craig.
So then I'd assume Steve's script as posted in Reply #55 would not have run with intended results.
Maybe not the main problem, but a problem none the less.
Just observin',
Russ
-
Ya Nvr No,
I just double checked and I have exactly the same lines in my Screen Load Script.
Overloaded,
Good eye for catching that. You posted the case sensitivity question earlier and of course you are dead right. I have already changed that so that all of the var names match exactly. C is generally case sensitive in all flavors that I have used, so typos and also the dreaded 'cut and paste' typos can be hell. MS C helps a lot with that by popping up the var names as you type. At first it is an annoyance, but you learn to embrace it before long.
If you look at the image on post #58 you will notice that the debugger blew up on line 2. After your post, I fixed the case issue and no joy. I went a step further and as you see on line 2, the var content is hard coded into the argument and it still blew up at the same place. That exact var is used in the now infamous M40 and it works fine, so it is not the argument causing the problem either.
It is a mystery to me, but for now the 'Vaudeville solution' seems like the best course:
Patient: "Doctor, it hurts when I do this"
Doctor: "Then don't do that, NEXT!"
Badda BING!
Everybody,
I think it may be an issue with this computer. One of the images I posted (I think) showed Lua unhappy about something and calling out the IP of this computer.
There are a co0uple more things to try. One is to turn off the firewall and the other of course is to try the same procedure on my CNC computer (less complex and 32 bit). But the CNC computer is doing its job at the moment, so I can't mess with it.
It is good to know that it does work so the problem is on my end. I'm doing something stupid and obvious and just missing it completely -or- there is something in the OS of this computer that is blocking the calls.
As I mentioned, it's not something I plan to use right away . . if ever . . so knowing it works is enough for now. I can play with MACH4 using self contained scripts for now. I'm posting the issue here as the final resolution, if any, might be valuable. For example, I discovered that MACH4 has to be 'run as administrator' (at least on this computer) or the OS blocks the IP traffic. So . . that would be a good thin g to add into the install instructions. Certainly can't hurt and it may save some hair pulling down the road.
Once again thanks for the responses!
-
That's my point if you don't post your code, we are just guessing what your issue might be.
Sharing brings to light issues other might want to learn from too.
If ya don't want to share, pull your own hair. ;D
its just a joke... chill 8)
-
I think I have mentioned it before, but it is worth mentioning it again. There are two instances of LUA. One in the GUI and one in the mcLua plugin. The mcLUA plugin is there so that M codes will run regardless of what GUI is driving the core. It is NOT connected to the Mach4GUI in any way. However, communication between the two LUA instances is possible with Mach registers. But mcLua plugin based scripts and functions cannot see the Screen scripts as the screen scripts are imbedded into the screen set.
Mach 4 is written so that any developer can write their own GUI for the core. It can be written in C++, C#, VB, or any other language that supports loading of DLLs. We have two GUIs at the moment as an example of this. Mach4GUI and the wxMach "static" GUI. The static GUI is just that, static and not changeable. I do have a sample GUI written in C# that I played with. wxMach does not have a configurable screen and has no screen based scripting functions. It does, however, have a PLC script. So that is the reason for the separate LUA instances.
So on to global functions...
If you want a global function that can be called from any screen object script, put the functions in the screen load script. Then they will be available to all screen object scripts.
If you want a global function to be available to all M code "macro" scripts, put a file in the macro directory containing the global script functions. The file can be named anything as long as the extension is ".mcs". Say you named the file "myGlobalScripts.mcs". You can write this file using the mcLuaEditor. It is prudent to test the scripts (debug) and "compile" the file inside the mcLuaEditor to check for syntax errors. The act of compiling the *.msc file will generate a *.mcc binary file. Then when you press cycle start the first time, ALL of the *.mcc files in the macros directory will be combined into one LUA program called wxLua.mcc. This is the chunk that gets loaded.
What if you want the same global functions in the screen and macro scripts? You can duplicate the code in the screen load and the macros directory or you can "include" the code from the file system in each LUA instance. This "shared" code should be put in a global directory. Meaning not a profile's macro directory. Something more along the lines of a "Modules" directory in the Mach4 installation. That way all profiles or screens in you installation can access it regardless of if you happen to delete a profile or two. But I won't get into how to do all of this. The LUA manuals cover it.
Oh another thing... DO NOT expect any scripts that Brian or I post to just work. They are hand typed generalized examples of how to get something done. They are usually typed on-the-fly as we answer a post and they may not be perfect. They are close. But the only way to ensure they are perfect is to put them into the LUA editor, compile them, and tests them. That is not something we have time to do when answering a posts. It is an exercise for the user to make them work.
Steve
-
I think I have mentioned it before, but it is worth mentioning it again. There are two instances of LUA.
You may have mentioned it before, but this is the first I've read it . . . and it explains a LOT. I don't have much time these days for general perusing of any forums, so if it was not in my tunnel vision (i.e. this thread) then I would have missed it. What this is leading to is a big :-* for taking the time to repost here.
Oh another thing... DO NOT expect any scripts that Brian or I post to just work.
My bad for not catching the case and spelling typos. On the case sensitive issue, I know better, just missed it. On the spelling, I actually thought it might be a reserved word. Programmers do that stuff, sometimes just to be funny, sometimes with good reason. The basic public code I use to drive the Modbus is actually called Mudbus . . . to keep libraries from overwriting each other. Nobody is worse at typos than myself and I don't point them out just to bring attention to them. I was just asking if one of them was actually a keyword.
In any case, FWIW, I am trying not to waste anyone's time on Modbus 101 or to post code for others to troubleshoot. I have no way to analyze (what I thought were) MACH4 error messages, so I post them in case there is some value to that. Otherwise, I am quite willing to do my homework and plug away until I am out of options.
Brian already put us on notice that modbus is not the focus for the demo release and speaking for myself, your time spent on this topic is greatly appreciated. I am trying to be careful not to waste it and only ask MACH4 specific questions that only you can answer (until the docs catch up). If I post a question that is not MACH4 specific, it will be out of ignorance of Lua, so please feel free to tell me to RTFM, because I do have them and I'm happy to do the homework.
-
That's my point if you don't post your code, we are just guessing what your issue might be.
Generous offer, thanks. The code we are each using came from the same source; a post be a developer earlier in this thread. Save a few typos that have since been corrected, we are using, or at least starting with the same code. Of course our registers have different names, but that would not cause the kind of systemic problems that are occurring on my machine.
Win7 Pro 64bit, firewall, all manner of resident drivers (Render Farm, Raid arrays, a ridiculously long list of NIC features, Various .NET extensions and who knows what MS adds with their suites). It is not important the MACH4 demo work perfectly on this creature under my desk and I don't want to waste anyone's time unless I have a fail on the CNC computer as well. Steve just dumped a ton of new (to me) info on how the modules interact and where to put stuff. That one post has cleared up a lot of the mystery for me, but it will take some time to dig thru it and test everything he mentioned. I understand about 85% of what he said, but I'll need to crack a book to get the rest of it.
If you say the global calls are working on your computer, that's good enough for me. Most likely it will work first try on the very basic CNC computer. If so, then I'll just grab a similar PC from around here or build a new one to work on MACH4 development. I have a huge investment in MACH, so one new computer is peanuts in the grand scheme. No problemo.
-
Brief Update and info.
Global functions calls are now working :D
Combination of things, but get your notepads out because I have another rather esoteric bit of support info.
Another Win7 Pro 64 bit anomaly. Note that MACH3 did not complain about this nor the previously reported issue.
Naturally my main development computer is on internet and I am running TCP Modbus. I do not have two NIC cards in the beast (any more) , so to keep from switching back and forth, I configured TCP/IPv4 hard coded for two networks. I then entered the hard coded IP for internet into the CableONE router/modem.
That all works peachy . . with one exception, for whatever reason, MACH4 *seems* to be looking for Modbus on the Internet IP. This *apparently * only happens during calls to global functions. I would not swear to that, but I did get a Lua error referring to not getting data from IP *********.********* blah blah which was the Internet IP.
*Perhaps* this is related to there being TWO instanced of Lua. One using the hard coded (configured) IP and the other using the first one it finds active?
I don't know for sure where the problem is internally in the OS or Lua, but removing the dual hard coded IPs resolved the problem.
Prolly not going to be a common problem, but if you have Win7 Pro 64 bit tab in your support notebook, here's another entry for you.
BTW, I noticed the Modbus config window says Modbus Register . . . ;D
I think that's a wrap, Guys. Time for a tall Whisky Sour, my friends. I shall toast to you all who provided guidance and patience.
-
Tidbit:
D-Link DGE-530T NIC works with Win7 Pro 64bit and MACH4 TCP Modbus
I had one lying around, but I checked and it is still current and available.
Running Internet with built in NIC (Intel MB) set for Auto IP connected thru switch to CableONE router.
Hard coded IP on the D-link card for MACH4 TCP Modbus
Can run simultaneously. No conflicts.
FWIW
-
I learned alot from this thread, thank you.
I have an additional Modbus Question, is there a way to 'shut off' modbus , and turn it back on from a button script ?
-
OK, time to resurrect this thread since there is a lot of good stuff already in it.
Once again thanks to all who helped me the first time around very early on to get TCP Modbus working with MACH4.
There appears to be some good documentation now and a lot of work done by Scott and Craig and doubtless others on exposing some bones for the rest of us to chew on.
A brief recap: My porting effort entails moving a motor control system from MACH3 serial Modbus (yes, the old one) over to MACH4 TCP. Just when I though all the pieces were in place and I had some time to fool around with it, the realization came that I have a configurator program that runs in Windows and collects parameters from the user and feeds the to the controller via serial COM port. The objective being to get rid of serial interface, in all of its disguises, the Windows based Configurator utility had to go. I di not want to do ANY more work with the old serial Modbus, so I took the decision to convert the existing MACH3 system to TCP, eliminate the Widows Configurator and develop some new method of collecting, transferring and storing the required parameters.
All of that is now completed and the (development version of) Motor Controller is now on MACH3 TCP Modbus. Parameters are collected via macro and transferred via Modbus and saved on an SD card. E-stop is connected thru Modbus rather than hard wired and I have developed a method of monitoring the Modbus activity (or lack thereof) from within MACH3.
Hopefully this work will make it easier to port to MACH4 since it *should* be just a matter of replacing the functionality provided by MACH3 Brains with Lua scripts.
To quote on of the big dogs here: "shouldn't be that hard" . . . just a thought . . . :P
-
Incidentally, on a related topic, I said that I would report the results of compatibility testing with Ethernet motion control boards.
So far, I only have the ESS as there are no others with plug-ins (that I know of) but I can report the following with MACH4:
The Smoothstepper ESS runs fine along with MACH4 Modbus TCP in these configurations:
1) thru an Ethernet switch with no other networks active. (Using a more conventional IP address than the ESS default)
2) with a network active and the ESS and MACH4 Modbus thru a switch to a separate NIC card (not bridged).
I did not test these device on my business network (which includes the internet port) because I don't see any logical reason to run this way and DHCP does not work with ESS or Mach4 TCP Modbus as best I can tell.
If anyone is having difficulty setting this up, post back and I will provide the setting that I used. Although that should not really be much of an issue, it never hurts to use a known working configuration to eliminate potential causes.
-
FYI here is my modbus system. i use a pokeys 56E as both a Modbus TCP port and at the same time a 3 axis motion controller. the built in mach4 modbus TCP system works flawlessly, transmitting hundreds of datapoints in real time. 55 io ports, 6 10 bit analog inputs , 4 high speed position encoders and 4 counters in my case. the modbus i/o programs into the 'Mach' i/o configure with no issues. at the same time the built in poblocks programming language handles some very complex program execution all while the motion control sub-system drives 3 axis. not bad for 80 bucks.....so inexpensive i dont use a breakout borad for it, the big thing to me is that it works in real time. on the down side the pokeys motion control package works well for my simple machine, but the other built in plugin function not so much yet,
-
Machiner,
Thanks!, I'll take a peek at that.
I purchased a PoKeys 56U a long time ago and never used it for anything. Presumably the 'E' version is Ethernet, but obviously also a lot more.
-
New problem.
Uninstalled all versions of MACH4
Reinstalled from new 2230
On entry into config Modbus plugin, get this message:
(http://www.thecubestudio.com/Mach4Error.JPG)
-
There is an orphan node in the modubs settings (inside the profile's Machine.ini). Choose "no" or "cancel" and try to use the modbug config dialogs to get rid of it or edit the Machine.ini file.
Steve
-
I learned alot from this thread, thank you.
I have an additional Modbus Question, is there a way to 'shut off' modbus , and turn it back on from a button script ?
There is a register called "mbcntl/command" that can be used to control the modbus plugin.
hReg = mc.mcRegGetHandle(inst, "mbcntl/command");
mc.mcRegSetValueString(hReg, "start"); -- start modbus
mc.mcRegSetValueString(hReg, "restart"); -- stop then start modbus
mc.mcRegSetValueString(hReg, "stop"); -- stop modbus
You can also see the status by reading "mbcntl/status"
hReg = mc.mcRegGetHandle(inst, "mbcntl/status");
local status = mc.mcRegGetValueString(hReg);
You can test this out in the regfile diagnostics dialog. Just by changing the command register.
Steve
-
now THAT is useful!!
Is there any other calls to the register about modbus for:
1). Get the Serial and/or Ethernet Com error., i.e. Com disconnected etc.
2). Get if the user has or has not "enabled" the modbus Plugin (active, and should be communicating).
3). Is there a way, to get or set, Com "Time outs" and Get/set how many "Retries" before throwing
a lost communication error (watch dog type thing).
As the Evil Terry always says......... "Just a Thought"... .. HEHEHE
Scott
-
First, thanks to Smurf for the response, I will checkout the .ini
Scott, I will send you the .ini file intact as it is possible that either your MAD software, or my incorrect use of it, cause the gremlin because it started with the MAD install
Now a general FWIW. While I do not yet know how useful the built-in MACH4 Modbus 'monitor' will be, I am happy to have it and will investigate. Meanwhile, this is what I am doing to 'monitor' the TCP Modbus. This is a general description of the function. Please do not ask for the code. It is not generic.
1) in the device, track the number of modbus reads
2) send that number continuously over Modbus to MACH3 (I have not done this with MACH4 yet - and may not have to)
3) read the counts in MACH and compare each number to the previous.
A) read
B) store the value
C) start a timer of some kind
D) read again (after a longer period than the Modbus speed)
E) compare reads
F) if the reads do NOT match, Modbus is not only running, but the data is being passed correctly. If they do match, the com is broken, the device has locked up, of Mach has stopper sending queries for some reason.
There are doubtless lots of way to skin this cat. I am using the MacroPump to do this. In my setup, it actually is already in use for monitoring/sending E-stop to my Motor controller, and the Modbus 'monitoring' code was just added to it.
Since I do not want to pause the E-stop monitoring waiting for the next Modbus read, I am using the actual MacroPump execution loop as the timer.
So far it is working fine.
-
There is an orphan node in the modubs settings (inside the profile's Machine.ini). Choose "no" or "cancel" and try to use the modbug config dialogs to get rid of it or edit the Machine.ini file.
Steve
I did not find anything in the .ini relative to Modbus except Modbus=1. I searched on 'Mod' on 'Bus' and 'reg' and found nothing relating to Modbus. What should one look for in the .ini? This was a fresh install so perhaps there is no Modbus config data in the .ini yet?
On to success: I clicked cancel at the error message and was taken to the config screen, but it was blank as before. I clicked on the 'add connection' icon and got an input screen and was able to set up a Modbus connection.
Closing and reopening MACH4 and the Modbus config is working and it kept the first connection, so I think I'm off and running.
Thanks!
-
Update:
After configuring some Modbus connection/function the stuff showed up in the .ini
Scott, original .ini has no Modbus data, so it would not be useful.
Mach4 is once again talking to my processor, so I'm good to go for porting over the Mach3 stuff
-
So far I have only spent a couple of hours on the controller port and it is about 90% functional on MACH4. It turned out to be just ridiculously easy. Having the entire controller already moved to TCP Modbus and all serial connections (like the Configurator program) already removed, it was just a matter of setting up Modbus and making a bunch of screen buttons.
Except for . . . . I'm struggling with making the Y and Z axis data continuously stream to respective Modbus registers.
Should there just be a function created and stuck in the 'screen script' and is there a special function name that means 'run this function continuously' in the manner of the MACH3 macro pump?. Should there be a timing loop to throttle how much processing time such a script consumes?
Secondly, I have found no way to connect a slider to a Modbus register. Not an emergency, but is his doable?
Lastly another wish list item; is there, or will there be an 'image toggle' button. The toggles are uber convenient and a dream compared to MACH3, but they are also pretty ugly.
The first issue is the most pressing; streaming axis coord to a Modbus register. Actually two registers, one for the integer portion and another for the fractional portion, but I can take care of that if I can figure out how/where to put code to stream the data.
Thanks!
-
Use the screen PLC script to push the axis values to modbus. There is an interval to control the PLC script timing. If you want a function of that, just make the modbus update every other PLC script run or something along those lines.
You can connect a slider to a modbus register by also using the PLC script. The plc script should get the value of the slider via the scr.GetValue('control name', 'property name') function (I may not have that syntactically correct). Then push that value to the modbus register.
With wxWidgets 3.0+, toggle buttons can have images. We started with 2.8, so toggles never got images. So I will add that when I get a chance to get back into the GUI code.
Steve
-
Use the screen PLC script to push the axis values to modbus. There is an interval to control the PLC script timing. If you want a function of that, just make the modbus update every other PLC script run or something along those lines.
THANKS! That was the nudge I needed. I had to do some homework around the forum to figure out what PLC Script is, but all working well now.
Tremendously faster than MACH3! :o
The Axis data is used to calculate RPM based on SFM and OD during turning operations. This method is activated only in 'AutoSpeed' mode. To keep the CPU load minimal, I only turn on the streaming when in AutoSpeed Mode and then only for the axis that is being tracked. The CPU in the new MACH4 TCP version of my Motor Controller is about 5x (real world) faster than the previous version, so together with the uber fast MACH4 Modbus, I should get very close follow, instant response time (effectively) and very smooth ramping.
You can connect a slider to a modbus register by also using the PLC script. The plc script should get the value of the slider via the scr.GetValue('control name', 'property name') function (I may not have that syntactically correct). Then push that value to the modbus register.
Have not tackled this yet, but not a high priority. Should be no problem, now that I have the basic process figured out. Something I like about MACH4 (and Lua) is that once you get a certain process figured out, it works pretty much across the board. Each little thing you want to do is not 'slightly different' or need a particular work around.
At least that's my impression at the moment. 8)
With wxWidgets 3.0+, toggle buttons can have images. We started with 2.8, so toggles never got images. So I will add that when I get a chance to get back into the GUI code.
Steve
Perfect! It won't work any better, but it will look GOOD. and as Fernando says 'Is better to look good than to work good, and image toggle buttons will look MARVELOUS!"
-
Quick update;
Sliders are working fine. Better than fine, actually. I have two sliders, one for RPM input and one for SFM input. Each has a corresponding DRO that is both a readout and numeric input. The sliders are only active when the mode that they effect is selected.
E-stop is tied to the motor controller and it notifies the controller and turns off the spindle and disables the ON/OFF button while in E-stop. and leaves the spindle switched OFF at reset (so the spindle does not suddenly start up again on reset). All relatively simple tasks to accomplish in MACH4. These same tasks required a lot of 'smoke and mirrors' as well as a MacroChargePump in MACH3. Switching off the spindle and leaving it off on reset was a fairly good sized PIA in MACH3. In MACH4 it took literally a few minutes and no workarounds and it functions reliably and instantly.
The last task in porting over the controller is a program to collect and feed user parameters to the controller for storage (previously in EEPROM, now on an SD card). This program will use Modbus to send the collected data to the controller, but since I hope to make a nice looking single input screen for al of the parameters (like the original Windows 'InTurn™ Configurator' program), I will take that task over to the 'Scree Ideas' thread where this stuff seems to be happening, and then come back here for the Modbus functionality.
Impression: MACH4 is worlds apart from MACH3 as a development base. Literally in a few hours I have been able to accomplish in MACH4 (starting with zero experience and not knowing Lua) what took days and much frustration to accomplish in MACH3. ;D
Specific to Modbus, I have noted even after everything is configured and working, MACH3 sometimes starts up with TCP Modbus unconnected and a restart is needed to get it going. MACH4 is somewhat unstable while writing scripts, but so far it has never started up with Modbus dead and needed a restart.
Apart from the ugly screen, MACH4 is 'looking' very good to me at this point!
-
The screen can be changed to anything you like. It is a bit spartan. Believe it or not, that screen design is over 15 years old! It came from my milling machine GUI front end for Galil controllers way back in the 90's (before I stumbled upon Mach3). When we were developing the Mach 4 core, and hadn't really done a GUI or any sort at that time, we needed something quick and dirty to test with. So that old code/screen design is what I had from way way back and it became wxMach. Then when we did the user configurable GUI, the test was to see if we could duplicate wxMach with Mach4GUI. And we did, as unfortunate as it may seem. :)
I'll be the first to admit that I have no "flare" for GUI interfaces. Not my cup of tea, so to speak. In fact, I can't do anything artistic as it pertains to drawing or anything visual. I have to leave that up to people that have the talent for it. I like DOS screens. And I think the Fanuc screens are "works of art". :)
Steve
-
I'm just waiting for a paintbrush and I'll take it from there. The 'paintbrush' in this case is images on the toggle buttons.
I have seen from other posts that there is a way to add large images, so the ugly background is probably pretty easy to replace. Nothing we can do about the ugly buttons until you (or whoever) implements the image Tbuttons. Yes, the non-'T' buttons can have images, but the 'T's are just too convenient to use
Personally, what I would like to see is a screen with only a single big button in the middle of the screen labeled 'Make Part' . . . . . ;)
Not sure who to credit this to . . Mark Twain maybe . . . who was admonished by a female patron in a bar for being overly inebriated. He replied 'Yes Madam, I am quite drunk, however, tomorrow I shall be sober and you will still be ugly' . . . .
-
Incidentally, I started on a 'configurator' program by plagiarizing the BoltCircle Wizard. Slow going and I suspect down the wrong road.
-
HIYA Steve, Just a suggestion but doing the BoltCirlce Wizard example is the HARD way. I have worked with it and it is a beast. Do try the WxFormBuilder I think you will like it over the LUA way.
Just a thought, (;-) TP
-
HIYA Steve, Just a suggestion but doing the BoltCirlce Wizard example is the HARD way. I have worked with it and it is a beast. Do try the WxFormBuilder I think you will like it over the LUA way.
Just a thought, (;-) TP
Hey Terry,
Thanks, I'll give that a try. The BoltCircle wizard is difficult to comprehend with no documentation and it seems like the syntax is not standard Lua, so I'm sort of scratching my head wondering where some of the stuff came from . 'math.sin' and stuff like that.
The code that I added is just the normal Lua syntax and calls from the MACH4 'LuaCALLS.txt' file, so I should be able to just drop them into another program and not loose all of that time.
Did you use WxFormBuilder to create your wizard?
-
As soon as I downloaded and started to play with the FormBuilder it became apparent that it was used to create the sample MACH4 Wizards.
Since I am already pretty far along with modifying the supplied sample BoltCircle wizard (the screen ops are relatively minor compared to the 'guts' of the program), I'll finish on that base and do the next project from scratch using the FornBuilder Tool.
-
All done! Probably a lot easier and faster to start from scratch with a tool like the Formbuilder that to reverse engineer an existing example.
Formbuilder apparently generates 'project files' which one might assume have all of the resources used in the form making it very easy to go back and edit the screens that you have made. You miss out on this if you start outside with an existing screen program.
This little configurator finishes my project, so far as it relates to Mach4, so I'm off to other tasks, but I'll stay subscribed to this thread and answer questions if I am able to.
-
It wold be NICE if there was a Wizard Builder similar to the screen builder. The Wxformbuilder is NIVCE to look at but NOT very intuitive. I cannot find a proper manual and the Youtube vids are not very helpful. Out of focus ,no audio and they try to go at the speed of light with no explannations. Typical of LUA stuff very little docs .
BUT ONCE you spend 4-5 days figuring out the very basics it is still a lot easy than doing it in Lua from scratch.
Maybe someone here could do a Youtuber and take their time in explaining the basics to create a simple Wizard with bells and whistles.
That would be a big help to all.
Just a thought, (;-) TP
-
Right now I don't have time to really dig into the wx tools. My first impression is that the tools *seem* use an extension or library that has different commands and different syntax than Lua, so at this point I am not convinced it will be the nirvana that is has been described as. I have only a tiny bit of experience with it at this point, but in general, I find it can be frustrating to bounce back and forth between languages and wxFormBuilder sort of forces that on you even though everything is in 'Lua' . . . . supposedly.
If you need to make a lot of forms and you bounce back and forth between the several languages that are supported, then undoubtedly having a single tool to kick out code in each language would definitely be a significant time saver. For example if I needed a 'form' in C++ that is identical or very similar to one that I already did in Lua, and if that can be loaded into wxFormBuilder and simply regenerated in another language . . badda bing!
Terry, speaking of forms, what is the status of your wizard. You were going to attack treading next and you were going to give me a sample to play with.
-
The screen can be changed to anything you like. It is a bit spartan. Believe it or not, that screen design is over 15 years old! It came from my milling machine GUI front end for Galil controllers way back in the 90's (before I stumbled upon Mach3). When we were developing the Mach 4 core, and hadn't really done a GUI or any sort at that time, we needed something quick and dirty to test with. So that old code/screen design is what I had from way way back and it became wxMach. Then when we did the user configurable GUI, the test was to see if we could duplicate wxMach with Mach4GUI. And we did, as unfortunate as it may seem. :)
I'll be the first to admit that I have no "flare" for GUI interfaces. Not my cup of tea, so to speak. In fact, I can't do anything artistic as it pertains to drawing or anything visual. I have to leave that up to people that have the talent for it. I like DOS screens. And I think the Fanuc screens are "works of art". :)
Steve
I see that image T-buttons has been added! That was fast! I tend to think of 'MACH Time' as 'Bullet Time' in the movie; Matrix. I may have to revise that thinking ;)
So that we may compare Cinderella before and after I am attaching the first round Mach4 InTurn™ screen in all its ugly dress. Then I will post again when it's ready for the ball.
-
Since pretty MACH3 screens are not really related to Modbus, I started a new thread for Mach4 screen GRAPHICS specifically and posted my first experiments in 'Purdy Screen' there. There is a tiny video of a first try at a lighted rocker switch . . 8)
http://www.machsupport.com/forum/index.php/topic,29442.0.html (http://www.machsupport.com/forum/index.php/topic,29442.0.html)
-
I am doing some poking around to see what is available in the way of analog input to MACH4. I have seen some references to the 'analog register' in Modbus, but now I cannot seem to find it again. I also recall seeing something about getting the MgHz from a VFD or something like that. Again, can't seem to find it now.
So the question is;
Is there and facilities in the MACH4 Modbus implementation specifically for analog input.
Since Modbus, but spec can only xfer 16 bit numbers, it would seem that any analog (or PWM) would need to be converted on one side and interpreted on the other. But is seems like its worth asking the question, jus in case.
-
There is no such thing as an analog register in Modbus, just holding registers, input registers, output coils and input discretes.
To read an analog value such as a potentiometer, your modbus device such as a ModIO will need an analog to digital converter, putting the value into an input register (or holding). Modbus then transfers this as a 16bit Register to Mach4. You can then take this 16 bit value and apply it to whatever you want such as spindle speed override, etc.
Cheers,
Peter
-
Yeap,
Got Pete's MP-03 pendant kit based on his Mod IO reading/writing modbus: Digital Inputs/Outputs,
Analog in, MPG and Strings out to the LCD, just LOVE the Mod IO an awesome piece of work. It is running gang-busters with mach4's modbus.
Thanks for a great product Pete!!
Scott
-
There is no such thing as an analog register in Modbus . . .
Certainly not per Modbus spec. I think maybe what I was reading was just a reference to a Modbus 'analog' register was just descriptive of the use of the register for xfer analog data (after A/D). I have a separate thread going about getting analog into MACH4 in general. I just posted here specifically about Modbus.
The application is a 0-10V DC signal from an Industrial AC servo drive that tracks motor load. The solution does not need to be Modbus. A plug-in is fine so long as it is stable and not serial interfaced (including USB). So far the options I have collected are the analog inputs on the Arduino DUE processor board in my 4th axis motor controler, and a Pokeys board.
Does Homann have a solution that will accept a 0-10v DC signal and connect via Ethernet?
-
Any idea on why I don't get any com ports in the drop down menu for ports in modbus setup?
Thanks
Dave
-
We use the WINAPI EnumPorts() function to get the ports. This API call is part of the printing subsystem. Check to see if that is disabled/not installed on your machine. It might be something like "print spooling" or the like. If it is XP embedded, print support may not even be installed.
You are the first to see this that I know of. So I would be very interested in what Windows version you are running.
Steve
-
Thanks Steve,
when I installed xp I stripped out anything I didn't think I had use for on a cnc machine with n-lite. never planned on using a printer... no games, no media player. ect. it's only intended purpose was to run the machine.
Thanks
Dave
-
Setting up coils in Modbus does not create registers.
How are coils accessed in LUA?
-
Never mind. Figured it out.
-
This is a MACH3 Modbus question, but is related to MACH4. I have done a forum search and did not find an answer.
I have been tinkering with 'bitpacked' registers in MACH4 TCP Modbus and it all seems to work fine . . . BUT . .
My device currently works with both AMCH3 and MACH4 and before I change over to using bitpacking in MACH4, I would like to know if the same function is working reliably in MACH3 TCP Modbus. I have read variously that is works and also that it is broken. Certainly I could just try it, but even if it works, that does not necessarily mean it is reliable.
What is the current status of bitpacking in MACH3 TCP Modbus?
-
Is Ethernet Modbus working in M4? I went through a few pages of posts and it seems everyone is working with serial Modbus. The device I'm connecting to requires Modbus TCP.
Thanks
-
Modbus TCP works fine in MACH4. I have not tried Serial Modbus in MACH4
-
Cool. That's good news.
-
For what it might be worth;
Working with a CLICK PLC (Serial Modbus). I just got it working. Only issue for me was I could not "Enable 485 Mode" in Modbus setup. I had to open my MACH4 .ini file and edit RS485=1 Then all was good. See pics if interested.
MACH4v2441
Regards,
-STrack
-
I had to open my MACH4 .ini file and edit RS485=1
Uber impressive that a user with only 4 posts could figure out how to directly edit the INI file to work around a MACH4 issue. Kudos on that!
I have a question posted earlier which has gone unanswered, so I will add another FWIW here;
On the topic of Bit packing, I have done some research and testing and my findings are that Mach4 unpacking seems reliable and fast and I will be using that feature.
MACH3 on the other hand, I found to be unreliable, restrictive and slow and in that application for both bit packed and coil data.
As a consequence, I have written my own bit-packing routines and will let MACH4 unpack the 'control word' and that task will be performed with a VB script on a normal register for MACH3.
It is known that bit packing was broken in MACH3 for a long time and the unwillingness of anyone to step forward and state that it is currently working in MACH3 is an indication that it is still unreliable even though it *seems* to be working.
-
I've always used bit packing with Mach3, it's been reliable, so I don't know why you say it is broken.
Peter
-
I did not say it is broken. I asked a question . . over week ago . . which was not answered . . . as usual.
In fact I said is *seems* to be working.
In any case, having received no response, I created a solution that renders the whole question moot. Done deal. Movin' on.
-
Bit packing does work in Mach4
see the modbus tutorial/example in the tool box, it uses bitpacking to/from the screenset.
-
Bit packing does work in Mach4
see the modbus tutorial/example in the tool box, it uses bitpacking to/from the screenset.
From my previous post ; "Mach4 unpacking seems reliable and fast and I will be using that feature."
MACH3 was the question, but that has been resolved (for my application).
-
Unsubscribed . . . .
-
im
-
I downloaded Mach4 yesterday. Played a little. Not sure if it worth continuing....
I setup a Arduino Mega that is working nicely in Mach3.
I am reading 12 holding registers in Mach3, with minimum 25ms function configs. No problem.
Its a setup a RTU serial function running at 57600baud. I setup the same in Mach4 today.
Reads at 900ms polling interval.
At 900ms the modbus diagnostic tool says the transactions are taking 23-24ms.
Polling rate of 800 or less and it fails and says timeout!!!
I have read from this device faster than 25ms outside the Mach world.
Whats up with Mach4?
I searched polling interval on here and other terms. Nothing.
Only doc (poppabear) say something about only getting 600ms cycle times.
Can Mach4 actually read modbus at any useable rate?
-
For what ever reason, at least with the MEGA,
The max you can set the baud is 19,200, and you have to set the scan rate at 1000ms, and the timeout to 2000ms.
if you try to lower the scan rate, or raise the baud rate, it errors out...........
Scott
-
Scott,
The problem is not with the MEGA. I have one on my desk running at 460,800 Serial talking to the venerable old SmartTerm program while simultaneously talking to a touch screen at an even faster rate. I use SmartTerm because the Arduino Serial monitor tops out at 115k
I would look at the Modbus programming on the MEGA and in particular the interrupts being used. In my experience, interrupts do not work properly on the MEGA. Not the Atmel chip necessarily, but the Arduino board definitely.
I run serial Modbus to MACH3 with a MEGA at 57k baud all day long. It can run 115, but I back it down for some headroom.
I have a question about MACH3 TCP Modbus; I am testing a TCP Modbus device with MACH3 and while running Modbus TCP, MACH3 is using 45% to 52%of one side of a 3.2 ghz Core Intel dual processor. Jogging is sporadic with DRO updates happening in 'chunks' rather than smoothly. Turning off the Modbus results in smooth MACH3 operation and 2 to 3% CPU at idle.
Is this normal?
-
I've always used bit packing with Mach3, it's been reliable, so I don't know why you say it is broken.
Peter
Interesting post made only two weeks ago by 'poppabear'
http://www.machsupport.com/forum/index.php/topic,30299.msg210714.html#msg210714
the "Bit-Of-Word" (or bit only), is broken in Briais, (in other words the Bit-packing) does not work.
for each "Bit" you want to control, you have to send the entire word for that ONE bit.
Scott
-
I have a question about MACH3 TCP Modbus; I am testing a TCP Modbus device with MACH3 and while running Modbus TCP, MACH3 is using 45% to 52%of one side of a 3.2 ghz Core Intel dual processor. Jogging is sporadic with DRO updates happening in 'chunks' rather than smoothly. Turning off the Modbus results in smooth MACH3 operation and 2 to 3% CPU at idle.
Is this normal?
FYI, I was having the same issue with very high processor usage when my Pokeys 56 Ethernet was enabled. I had to get a different motherboard and the issue went away.
Joe
-
I have a question about MACH3 TCP Modbus; I am testing a TCP Modbus device with MACH3 and while running Modbus TCP, MACH3 is using 45% to 52%of one side of a 3.2 ghz Core Intel dual processor. Jogging is sporadic with DRO updates happening in 'chunks' rather than smoothly. Turning off the Modbus results in smooth MACH3 operation and 2 to 3% CPU at idle.
Is this normal?
FYI, I was having the same issue with very high processor usage . . . Joe
Is this with MACH3 or MACH4?
-
I have a question about MACH3 TCP Modbus; I am testing a TCP Modbus device with MACH3 and while running Modbus TCP, MACH3 is using 45% to 52%of one side of a 3.2 ghz Core Intel dual processor. Jogging is sporadic with DRO updates happening in 'chunks' rather than smoothly. Turning off the Modbus results in smooth MACH3 operation and 2 to 3% CPU at idle.
Is this normal?
FYI, I was having the same issue with very high processor usage . . . Joe
Is this with MACH3 or MACH4?
Mach3
-
I have been fooling around with modbus for a few hours, and I have discovered something I didn't find in all of the searching of documents and fora that I did.
When you are setting up a Functon in modbus in Mach4, even though you have to select the Function type, such as, "Read Holding Registers 16 bit (0x3)", you also need to put the prefix (in this case, "3") in the box labelled "Register Name Prefix".
Not very intuitive; I did it sort of on a whim when nothing worked.
Seems like that box should be labeled "Register Address Prefix", as it has nothing to do with the name. And why is it necessary to put in the prefix, if I have already selected the Function type, which implies the prefix?
Anyway, I am finally talking to my VFD.
I thought maybe somebody else would find this useful when they dig in to modbus.
-
The function type and register 'name' are not related.
The register 'prefix' is a starting point for your register names.
Mach4 uses that prefix to pre-populate the register names only as a convenience. You are then free to go back and edit these names as well as ass ancillary descriptions in a separate field is desired to help identify the register or put notes on what the register controls or where the data comes from or any other information that may save your butt a year down the road when you are trying to do some improvements or maintenance on the system.
The Register 'name' is important because that is what MACH4 uses to access the register. If you have used Modbus in other applications and had to use only register numbers with a separate 'cheat sheet' to know what is in each register, you will love this feature of MACH4.
I have attached a screen grab of a section of one of my MACH4 Modbus Diagnostics. NOte that to access these registers in MACH you would use the actual name ex.
"modbus0/Encoder_Inturn_Switch"
Note also that on that register, I have added in the 'description' info on the source of the data (InTurn_Bit_OUT34-15) which identifies the var name and the pack bit number at the source.
In this particular application, there are about 40 registers, 3 of which are bit packed inputs and two are bit packed outputs. loop time on this averages about 20ms.
3 words to describe MACH TCP Modbus:
Convenient
Stable
FAST . . . no make that Wicked fast!
-
FYI, I was having the same issue with very high processor usage . . . Joe
The slammed processor issue was only with MACH3 and had to do with the way it polls Modbus. Changing the Ethernet port (which is probably built into your MB) most likely is what solved the problem. A new/different driver may have also solved the problem as well as an ad-in NIC.
Modbus can 'respond' or 'loop' and in latter case, changing the loop frequency can solve the problem.
-
How do you perform two way communication with the Holding Registers?
I have both the LUA Read and Write Functions that are specified in this thread (THANK YOU)
I start out with everyone at 0 (picture1)
When a value is placed in MACH (I setup a Modbus write Function(0x6)) and send it (I use a button that calls the LUA Send Script defined in this thread) It goes over to the simulator (MODBUS_RSSIM) and I can see it in the Holding registers (Picture2)
I can also set a new value in the simulator and send it back to MACH which displays it just fine (I use the Modbus Read Function(0x3) and a DRO) (Picture3)
My problem is that I can no longer send the value back to the holding register because the writeRegisters (0x6) has the same value that I sent previously and will not resend.
What is the normal process for two way communication through Modbus?
Of course, trying to send through the read function(0x3) doesn't work.
What am I doing wrong here? Do I need to do some sort of Comparison script in LUA that updates the write Function to MATCH the Read Function?
-
So here's my hacky solution to my problem above...
function setModbusValue(aModbusInstance,aModbusID,aModbusValue)--This sets modbus data by passing the modbus instance (modbus0) and the register ID
local rMbHndl = mc.mcRegGetHandle(inst, aModbusInstance .."/".. aModbusID); --Get the current Read Register Handle
local wMbHndl = mc.mcRegGetHandle(inst, aModbusInstance .."/".. "w" .. aModbusID); --Get the current Write Register Handle
local rRegVal = mc.mcRegGetValue(rMbHndl); --Get the read Value
local wRegVal = mc.mcRegGetValue(wMbHndl); --Get the write Value
if rRegVal ~= wRegVal then --Sync the Write Register to the read register
mc.mcRegSetValue(wMbHndl, tonumber(rRegVal));-- Sync the current value which DOES NOT trigger a send
end
mc.mcRegSetValue(wMbHndl, tonumber(aModbusValue));--Send your new value which can also be the old value
end
You use the read register name as the input to the function and capture the write register in the function (see the comments)
The Catch here is that you have to preface all of your MACH write registers with a "w". This is cumbersome at best and leads to problems down the line.
What I should probably do is use the Write function as the input to the function and then remove the "w" from the front of the name and check for a read register element. I just got lazy from all the frustration
-
I changed the code so that it uses the Write Multiple Register Elements so that you don't have to have a corresponding read element
To use the LUA function below, place it in the Global Script. then, you need to place a single char (I use a "w") on the front of each element name for the MACH write function elements. So you create a series of Write Multiple Register 16bit (0x10) elements in Mach4 and each name is prefaced with a single letter (wWrite1, wWrite2 etc).
Then you simply call the function like so: setModbusValue("modbus0","wWrite1","<DATA>");
This will call the function which checks to see if you have a corresponding read element (Without the "w" at the beginning). If it finds a read element it simply changes the write element value to the current read element value -prior- to writing the actual value that you want
Let me know if you have any questions or, if you know of a way to do this without all this silliness...
function setModbusValue(aModbusInstance,aModbusID,aModbusValue)--This sets modbus data by passing the modbus instance (modbus0) and the register ID
local rMbHndl = mc.mcRegGetHandle(inst, aModbusInstance .."/".. string.sub(aModbusID, 2)); --Get the current Read Register Handle (Removes the first Character from the name)
local wMbHndl = mc.mcRegGetHandle(inst, aModbusInstance .."/".. aModbusID); --Get the current Write Register Handle
local rRegVal = mc.mcRegGetValue(rMbHndl); --Get the read Value
local wRegVal = mc.mcRegGetValue(wMbHndl); --Get the write Value
if rRegVal ~= wRegVal then --Sync the Write Register to the read register
mc.mcRegSetValue(wMbHndl, tonumber(rRegVal));-- Sync the current value which DOES NOT trigger a Modbus send
end
mc.mcRegSetValue(wMbHndl, tonumber(aModbusValue));--Send your new value which can also be the old value
end
-
Hi Guys,
ive made a very easy setup tutorial for the MACH4 MODBUS and Spindle Control
watch the full post and tutorial here:
http://www.machsupport.com/forum/index.php/topic,38560.new.html#new
regards cncprint.blogspot ;D