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.

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.

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


  

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.

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.  I noticed the greatest latency when using functions in button scripts to adjust DROs. Then using the button to set a flag value in which the PLC catches and references a function in the screen load up script was still a little off but not as much. The best method was just to write the function in the PLC, so the PLC will only execute the function if the flag's value is true. I observed this with in->mm conversion DRO's. The best return is six ten thousands off exact value. Now, if you are in mm to begin with (config settings) it will be exact.

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?

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.

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.

I totally understand you are not arguing. I appreciate your time and response. This is how I learn. I mean, I was legitimately asking these questions. I really wanted to expand my knowledge with m4, especially in this scenario (MPG/jogging/resource conflict/timing/processing, etc). It is important to me to respect all views and alternatives. Sharing lessons learned and best practices is why I choose to be apart of this forum. It's the communication and topics like these that I am proud to apart of the m4 community. Thanx!

-josh

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.



 

the way crazy lou`s LOL (black screen of death) going he might get a job out of what he is doing he seems to be picking it up very fast

 Positivity is contagious.

yer man you are doing quite well you should do your own screen set and other bits as you are and sell so you can take the girlfreind (mistress) out

I'll take her on vacation to New Zealand and leave her with you. Then I can actually get some work done then