Messages

41

Mach4 General Discussion / Re: Disable button border??

« on: July 01, 2015, 05:08:35 AM »

Simpson posted some info on this a few months back.

Mach4 screen GRAPHICS -- makin' it Purdy - read all of that but nothing there unless Simpson found it and forgot to say

DazTheGas

I did not forget, I gave up in utter frustration at the developer's lack of interest in supporting people who are willing to spend their time working to provide MACH4 a more ergonomic and professional GUI  . . . and sharing that with the community.   Perhaps the most worrisome things about MACH4 is lack of support.

While I fully recognize that a user oriented screen editor must have certain restrictions to prevent novices from completely destroying the integrity of the system, refusal to add a feature like turning off button borders can only be pure stubbornness on the part of the MACH4 team.

The reason I wanted the borders off the buttons was to have flexibility in adding realistic images of controls, but it turns out that the alpha channel is not working right on the MACH screens (initially I thought it was), so the usefulness of turning off the button borders will only result in advancing to the next roadblock, which again would require assistance from the developers . .  so I just threw in the towel on using the MACH4 supplied utilities and relying on the MACH4 team to support the effort.

Having said that, it turns out to be an ill wind, because in researching alternatives, I found the 'real' toolbox full of tools in the LUA world. There are several very powerful graphics extensions in addition to wx and pretty much anything I can dream up is doable, but the methods are too advanced (in my opinion) to be sharable on a hobby forum.  However, progress did not cease with the last post in that thread you mentioned, I simply stopped participating because the MACH4 tools are not being used.

You have already discovered the method, you just need the tools. Start with source forge and other repositories where you will find and recognize the example code that has been posted in this forum with two lines changed and the author credit removed. Move on to general google searches which will turn up a whole world of stuff. Pick out what suits you and dig in.  You don't need to be held hostage by the MACH4 team.

Yes, I do have a bit of an attitude about this topic. I do not like having my time wasted on futile efforts.

42

Mach4 General Discussion / Re: MACH4 - Modbus

« on: June 25, 2015, 11:53:55 PM »

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?

43

Mach4 General Discussion / Re: Jogging/Pendant Interface-What is the best way? Ramblings

« on: June 25, 2015, 11:37:53 PM »

I totally understand you are not arguing.
-josh

A poor choice of words on my part. Probably one of the most troublesome words in the English language  (that is if you can conceive of English as a language ), given the diametrically opposed definitions, both of which are accepted and used commonly. Mr. Webster states:

: to give reasons for or against something : to say or write things in order to change someone's opinion about what is true, what should be done, etc.

: to cause (someone) to decide to do or not do something by giving reasons

: to disagree or fight by using angry words

My use was the first definition. i.e. to 'make a case for' as opposed to contradict.

This forum needs new members and new ideas and new questions and people who are not afraid to post for fear of the last definition of 'argue'.  I don't want to discourage anyone from posting an idea, no matter how silly it may seem to them, because you never know where the next great idea will come from, and it is often from a most unexpected source.

My wife is a project manager for a large Heath Insurance Company and is not technically versed in any of the activities that I swim in every day. It happens that I am developing a product that has 'cells' which contain what I will call 'action items' for the sake of discussion. I asked for an opinion of the process of individually changing the contents of the 5 cells ( in lieu of having pre determined sets of five). Her first response was "can you have 'favorites' ? ". This is a brilliant idea that never occurred to me at all, but has now on been added as a design goal.

While I would not term such a feature as 'favorites' per se, the concept of having a certain useful grouping of actions to go with a particular process is really no different than having a particular set of tooling for that process. Often the best ideas are the ones that seem all so obvious . . . once they are presented.

Enthusiasm is as important as skill or knowledge in actually accomplishing a goal. In this thread, Tim has demonstrated quite frankly amazing leaps forward in mastering a complex task and you have provided endless enthusiasm about anything and everything that even remotely resembles MACH4.

I hope that these examples are contagious and a career lurker or two will chime in. I'm always looking for the next great idea . . . from that most unlikely source.



 

44

Mach4 General Discussion / Re: Jogging/Pendant Interface-What is the best way? Ramblings

« on: June 25, 2015, 08:23:41 AM »

I really like using event flags (ie. if flag = some value then reset or reassign flag value; call some fancy function end <- in the PLC) and then defining global flag variables and associated function in the screen load up script therefore all that is needed is to set some action or button press to flag = 1 for example.

It is really interesting that you have observed greater latency with signals, whereas for example.... once a signal is sent/received the signal script will reference the signal table and execute the associated function.

'Latency' in this case would be the time between the command and the execution at the top level. There is more 'under the hood', but I would not know what that is. In terms of scripting, the delay would be the time it takes until the next pass of the PLC to pick up the flag. The frequency of PLC runs is user configurable.

Both processes will execute an action based on an event. It's really the samething in my mind. signal states = flag values...if 'true' then reset; execute else 'false' end. 

Yes, but as I mentioned, I do not know how the signals work internally in MACH4, so whether they are 'released' or are interrupting the processing is a question for the developers. It is possible that the 'signal' is generated along with a 'return' and sent along its merry way so the processor is not interrupted, but I do not know that rather important detail, so I err on the side of keeping the response functions as brief as possible, as is required for 'real' interrupts.

I mean as far as processing.. (this is my question)...everytime the PLC runs it tests only the conditional statement. If false then the PLC will skip to the end and continue. The PLC will not even go over the event function. Therefore, the only additional time required by the PLC is to evaluate one line...until, the condition is true. Correct?

If I understand your question correctly, then yes. I have read what I could find on this forum and the available docs relative to signaling and I do not recall any references to timing, but it would be good info to have if the developers chose to disclose that detail.

So if timing is an issue shouldn't we just write our functions in the PLC? ...and then events in which time is not an issue, those functions can be defined and referenced from the screen load up script.

The PLC runs at specific intervals and signals can hit at any time. The signals, as I understand it, can call a function made 'resident' by the screen load script, so that chain of events is not limited by some arbitrary frequency as is the PLC.

I want to be clear that I am not arguing for or against the use of signals. There are applications where the immediacy of signaling is important and applications where it is not. My suggestion was  a 'best practice' method to use signals (to the extent they mimic interrupts), not when they are appropriate to use.

45

Mach4 General Discussion / Re: Jogging/Pendant Interface-What is the best way? Ramblings

« on: June 24, 2015, 04:47:47 PM »

I plan to put it in a separate window next and/or both just replace the current jog tab.  You are correct the way it is implemented now is not practical nor very usable; a separate window will be much better.

In my view, a significant portion of our effort is an investment in learning the system. To that end, it makes perfect sense to experiment with multiple ways to do things. For example, I went a little nuts with the screen load script and signaling, but soon it became evident that not every action that CAN be moved to that location, is best suited to that method, nor is it convenient AT ALL to have the variables declared in a completely different place than where you will use them. So, I spent nearly as much time moving things BACK to the PLC from whence they came and unlinking processes from signaling.

Ultimately, it all contributes to knowledge of the system, so I don't consider it time wasted.

By your effort, you now have experience and knowledge of incorporating widgets into the MACH4 screens and also leaving them to float in their own window. Some processes will favor one  over the other, and now you can do either, as you see fit.

Polling was not the best choice but it was the only way I could see at the time to update the widgets on the screen.  Please note that the jog controls and jog input currently use signaling so the control inputs are not delayed by polling.  ONLY the images on the screen are updated by polling Not the controls themselves.

An approach to consider is to have the command side act on interrupts (signaling) and then have a 'last act' be updating the display data and/or resetting controls. In this way, you still eliminate polling, very little processor overhead is added to the (overall) interrupt response and the data display is always current and also acts as a monitor of the underlying actions.

An example: On my motor controller, the user (or an embedded macro) enters the desired RPM into a MACH screen DRO. It would be simple to consider that DRO to be the current RPM, but the RPM is collected from that DRO, sent to the controller, the controller compares it to an number of parameters and current operating conditions, calculates and sends a command to the DSS to alter the step stream frequency, and then reports the actual set RPM (which may or may not be what was requested) back to MACH for display in a separate 'current RPM' DRO.

In this scheme, the entire process is 'in effect' monitored and the returned RPM is an indication that the function was carried out. Also, if the RPM returned is different from what was requested, that indicates that an invalid (usually exceeding the motor's maximum) RPM was requested.

I don't know at this point if MACH signaling is uber sensitive to the complexity of the response (as are processor interrupts generally), but it is a good practice to keep the responding function as short as is practical. Unless there is a compelling reason to do otherwise, on interrupt, I typically just set a flag and return. The flag is then picked up, reset, and the actual response is executed. This adds some micro seconds to the response, but that is generally less consequential than running an interrupt response too long.

This may not all make sense to readers, but in a nutshell, if you are using interrupts or signals and you start getting system hangs, the likely culprit is the length of the functions being executed. In the specific case of an MPG, you would replace:

InterruptEvent -> process encoder input, have a beer, update screen, have another beer, reset controls, watch the game, -> return

with

InterruptEvent -> EncoderDataReadyFlag = true; -> return

A few millis may pass here, but it would require an extremely critical timing event to make a difference - very unlikely to effect an MPG. Most importantly, other interrupts can come in during this period and be processed and the system will not hang.

Here is the 'catch net' routine, which can be anywhere the program continuously loops:

if (EncoderDataReadyFlag) then
  EncoderDataReadyFlag = false;
  process encoder input, wash the car, visit aunt betty, etc, etc

  Now do all the controls stuff that used to be done by polling;

end

or if you are into functions:

if (EncoderDataReadyFlag) then
  EncoderDataReadyFlag = false;   -- don't forget to always reset the flag!
  DoEncoderStuff
end

Function DoEncoderStuff     -- I don't remember the correct syntax here

blah blah blah

end


  

46

Mach4 General Discussion / Re: Jogging/Pendant Interface-What is the best way? Ramblings

« on: June 20, 2015, 12:48:25 AM »

This is the latest version....Sorry, I don't detect the MPG motion yet . . .

  . . . This script is called by a timer event every ~200mSec and calls a panel refresh.     --Insert and scale a Lua Panel
   --Update the Lua Panel script with the MaintTab JogTab Lua Panel Script

TimGS,

Sorry I have not had time to follow your progress on this project. I was going to suggest you take a look at a sample 'mouse jogging' setup provided some time ago by Brian Barker and is floating around the forum. This sample uses the MPG functions and also is useful to review the difference in a floating wideget and one in a Lua frame both from the same code.

However, it seems you have had success in figuring this process out for yourself. Bravo! I have read the posts and noted that you are methodical in your approach and eat the elephant a bite at a time. This is a good model for readers to follow.

I have downloaded your code, but have not had time to peruse it. However, based on your description I do have two directions you may want to investigate.

First is to use signals rather than polling. 'Signals' in M4 seem analogous to interrupts and would be a better way to collect data from your hardware. Using this process prevents missed data and also eliminates the tremendous resource hog that polling will induce.

Second, although integrating a widget into an M4 screen is a great exercise in learning both M4 and Lua and wxLua, I don't think this is always the best approach for every application. Consider the advantages of a floating on-demand anytime jog window. For an on-demand anytime process like Jogging, why cripple the utility of it by chaining it to a specific screen or tab whereby other functions are now inaccessible?

47

Mach4 Videos / Re: Mach4 - Arduino and Touchscreen

« on: June 06, 2015, 09:26:51 AM »

Arduino IDE and Modbus info;

It may 'appear' as though all of the Arduino boards will run the same code, but that is largely due to a trick used by the Arduino IDE. It is a good trick and serves a good purpose for the intended audience, but it causes a lot of confusion when using third party libraries (like Modbus).

The IDE contains a file which has the required parameters for each Arduino board. You tell the IDE which board you are using. The IDE looks up the parameters for your board for use in compiling your 'sketches' [Arduino speak for 'programs').

This process is transparent to the user, so there is a common misconception that all Arduinos can run the same code, but that is far from correct. Code that compiles for earlier boards will not necessarily compile for the newer boards if Arduino has not yet updated the libraries or provided new ones. When you download and install the latest IDE, you also get the updated libraries, but there is a catch . . . .  only the Arduino supplied libraries are updated.

This may have changed, but last I knew, there is no Arduino supplied Modbus library. There are quite a few public (licensed, but free) libraries  floating around, but most are quite old and will not work with the newer board. Some have been updated here and there and I *think* there may be bone that has been updated as far as the Arduino MEGA. I started with these little development boards right before the latest MEGA came out and when it hit the shelves, there were NO Modbus libraries that worked with it . . and I did a LOT of searching.

Ultimately, I took one of the libraries that 'sort of ' worked and re-wrote the parts that needed to be changed for the MEGA's processor and to include and call the MEGA's libraries.

Next up came the DUE board which is a massive improvement over the MEGA, however, extensive searching did not turn up a working Modbus SLAVE for the DUE.
It was Modbus purgatory all over again, this time requiring a much more extensive rewrite of the code I was using on the MEGA.

Another unexpected challenge is that the DUE has no EEPROM . . . as in NONE, and the new board was 3.3v only. Fortunately, the Arduino Ethernet 'shield' (Arduino speak for 'daughter card') not only was compatible with the 3.3v DUE, but had an SD card reader to store stuff . . . except that the SD library did not work on the DUE . .  catch 22. Eventually, that got worked out and the new DUE is buzzing along nicely.

The bottom line is that if you have to use a non-Arduino library, do not expect it to work transparently on any Arduino board. 'Private' libraries are likely to be board specific and even support library specific. The better news is that sometimes all you need to do is change the names of the include files to match the ones for your board.

Users will need to research the particular board they plan to use. That's why I stated in a previous post the choice of board, if you are not able to re-program or create your own libraries, should be determined, in large part, but whether a working library is available for it that you will need for your application.  

Keep all of this in mind before rushing out to get the latest and greatest ne board. I believe the newest board is based on the DUE. Similar to the relationship between the Leanardo and Yun

48

Mach4 Videos / Re: Mach4 - Arduino and Touchscreen

« on: June 06, 2015, 08:52:21 AM »

Now, if we can just get Simpson36 back in here....we'all should do a collaborative project with Mach4.  

You guys have passion and are excited about creating products for MACH4. New blood and new ideas being posted is exactly what this forum needs. I do not have time to do development threads at this time, but here I will post a bit about my projects in hopes that it will inspire and encourage any of the new members to strike out either on their own or in collaboration.  

Any of you can send me a PM with info on a new thread and I will participate as my schedule allows . .  which is not very much. Please do not send me questions via e-mail. Post here and I will answer if I can.

Here is some info on my current projects. I will provide more information on the Arduino question and Modbus question in a separate follow-on post.



I have two projects that involve the Arduino; Porting my 4th axis motor controller to MACH4 is completed. This is the controller: www.theInTurn.com The ported version looks the same . . just TCP instead of USB . .  and there are several added features.
Edit: Oops! I forgot to mention a new processor. Moving from the Arduino Mega to the Arduino DUE

The second project is adding 'super pendant' capabilities to the controller. That project is nearly complete. I am currently assembling the first prototype by neatly ( as much as is possible) combining this rat's nest:



and the rest of the components into this new panel [1st proto . . will probably change], which fits the existing controller box (for upgradability):




So there you go. Now get your own threads going with your projects!

49

Mach4 General Discussion / Re: Jogging/Pendant Interface-What is the best way? Ramblings

« on: June 04, 2015, 09:18:57 AM »

Tim,

Add a Lua Panel.

Open the scripting choice for the panel (second 'page' of parameters with tiny icon that looks like a page)

The editor will open.

Copy your code into the editor and save.

Save screen - exit MACH4 and restart.

Your wizard should be in the panel . . . although is does not size down, so you'll need a big panel . . 

You might consider leaving it as a moveable window. That way it will always be available.

50

Mach4 General Discussion / Re: Jogging/Pendant Interface-What is the best way? Ramblings

« on: June 04, 2015, 08:09:51 AM »

Next question...How do I get it into Mach4?

Very nicely done.

When you say 'into' Mach4, are you seeking to add your wizard to a Mach Screen, or connect it to the Jogging system?