Leaderboard
Popular Content
Showing content with the highest reputation on 06/22/2023 in all areas
-
MbTcp - Modbus TCP UDF
marcoauto reacted to kurtykurtyboy for a topic
Here is something that I have been wanting in AutoIt for years but sadly no one had created it yet. Well, I decided to hunker down and do something about it! I present to you, MbTCP - a Modbus TCP/IP UDF. What is Modbus? Modbus is a communications protocol commonly used to communicate with various types of PLC's, sensors, SCADA systems, and many other industrial applications. Modbus TCP is the ethernet variant (as opposed to Modbus RTU which uses a serial connection). This UDF takes care of all the behind-the-scenes legwork and makes it easy to get right to the data. No need to worry about which function codes to use or how to format the data. Modbus typically works on discrete coils and inputs (think BOOL) or 16-bit registers (think INT). However, some devices support 32-bit signed and unsigned integers and 32-bit floating point numbers. This is possible by reading or writing 2 consecutive 16-bit registers and formatting them on both ends. The UDF will take care of all that as well (although maybe not in the most sophisticated ways...😏 ). Because there is no standard for working with 32-bit numbers, it is necessary to have the option to enable or disable big-endianness. Similarly, not all devices start counting at register 1. Some of them actually start at register 0. The UDF allows you to define these parameters when creating the connection to the device. Available data types for input and holding registers are INT16, UINT16, INT32, UINT32, and FLOAT32. Function List: ; _MbTcp_Connect ......................: Open a connection to a remote device ; _MbTcp_ReadCoils ....................: Read 1 or more output coils (function code 1) ; _MbTcp_ReadDiscreteInputs ...........: Read 1 or more discrete inputs (function code 2) ; _MbTcp_ReadHoldingRegisters .........: Read 1 or more holding registers (function code 3) ; _MbTcp_ReadInputRegisters ...........: Read 1 or more input registers (function code 4) ; _MbTcp_WriteCoils ...................: Write 1 or more output coils (function code 5 and 15) ; _MbTcp_WriteRegisters ...............: Write 1 or more holding registers (function code 6 and 16) ; _MbTcp_Disconnect ...................: Close the connection to a device ; _MbTcp_DisconnectAll ................: Close the connection to all connected devices To get started, follow these easy steps: Create a new connection to the device using _MbTcp_Connect Call any of the available read or write functions That's it. The program will automatically clean up any connections that are left open on exit. You may also manually disconnect from any device if needed. The most basic example of use. Connect to a device and read one holding register starting at register 2. #include "MbTcp.au3" ;connect to device at IP 127.0.0.1 Local $iConnection1 = _MbTcp_Connect("127.0.0.1") If @error Then MsgBox(16, "Error", "Failed to connect to the Modbus device at 127.0.0.1." & @CRLF & "Error Code: " & @error) Exit Else ConsoleWrite("Successfully connected to device at 127.0.0.1" & @CRLF) EndIf ;read 1 holding register Local $iReadData = _MbTcp_ReadHoldingRegisters($iConnection1, 2, 1) If @error Then MsgBox(16, "Error", "Failed to read the Modbus value." & @CRLF & "Error Code: " & @error) Else ConsoleWrite("Value: " & $iReadData & @CRLF) EndIf The next example shows how we can format the data to return an unsigned integer instead of the default signed integer. In the following example, we connect to a device that uses big-endian word order and starts at register 0 instead of 1. Then we read and write a group of registers. I may add more examples here if needed. There are a number of Modbus simulators out there if you want to test locally on your computer. But I really like a tool named Mod_RSsim link. Let me know if you find any issues. I know I will probably end up needing to add a timeout option. MbTcp_20230620.zip1 point -
Difference between GuiSetState and WinSetState ?
pixelsearch reacted to Melba23 for a topic
Dan_555, There is a fundamental difference in how the internals of AutoIt deal with the 2 commands. I had a discussion with one of the then-developers some years ago: Dev: You don't want to use WinSetState over GUISetState on AutoIt GUI. M23: May I ask why? Dev: Because then the rest of the code wouldn't know the real state of the window and you will get unwanted (by AutoIt) behavior. Which I think is a pretty definitive statement. I would go along with Andreik's suggestion above: AutoIt GUIS = GUISetState - other GUIs - WinSetState. M231 point -
Ternary line for GUI loop?
littlebigman reacted to Werty for a topic
While GuiGetMsg() <> -3 And Sleep(10) WEnd1 point -
What's the purpose? You still need the loop to keep you app running. This reminds me of this.1 point
-
Double click on an item in a list
littlebigman reacted to Andreik for a topic
Actually it's quite indicate to return from WM_COMMAND as fast as possible and you can do it through a simple Dummy control and do all the processing in your main loop or elsewhere. Here is an example: #include <Array.au3> Global $hMain, $cList1, $cList2, $cList3, $cDummy Global $hList1, $hList2, $hList3, $aMsg $hMain = GUICreate('Example', 900, 300) $cList1 = GUICtrlCreateList('', 0, 0, 300, 300) $cList2 = GUICtrlCreateList('', 300, 0, 300, 300) $cList3 = GUICtrlCreateList('', 600, 0, 300, 300) $cDummy = GUICtrlCreateDummy() $hList1 = GUICtrlGetHandle($cList1) $hList2 = GUICtrlGetHandle($cList2) $hList3 = GUICtrlGetHandle($cList3) GUISetState(@SW_SHOW, $hMain) GUIRegisterMsg(0x0111, 'WM_COMMAND') ; WM_COMMAND ; Add some lines in each list For $Index = 1 To 5 GUICtrlSetData($cList1, 'Line ' & $Index) GUICtrlSetData($cList2, 'Line ' & $Index) GUICtrlSetData($cList3, 'Line ' & $Index) Next While True Switch GUIGetMsg() Case -3 ; GUI_EVENT_CLOSE Exit Case $cDummy $aMsg = StringSplit(GUICtrlRead($cDummy), '|') Switch $aMsg[1] Case $cList1 Switch $aMsg[2] Case 1 ; LBN_SELCHANGE ConsoleWrite('Selection changed in first list.' & @CRLF) Case 2 ; LBN_DBLCLK ConsoleWrite('Double clicked in first list. (Item text: ' & GUICtrlRead($cList1) & ')' & @CRLF) EndSwitch Case $cList2 Switch $aMsg[2] Case 1 ; LBN_SELCHANGE ConsoleWrite('Selection changed in second list.' & @CRLF) Case 2 ; LBN_DBLCLK ConsoleWrite('Double clicked in second list. (Item text: ' & GUICtrlRead($cList2) & ')' & @CRLF) EndSwitch Case $cList3 Switch $aMsg[2] Case 1 ; LBN_SELCHANGE ConsoleWrite('Selection changed in third list.' & @CRLF) Case 2 ; LBN_DBLCLK ConsoleWrite('Double clicked in third list. (Item text: ' & GUICtrlRead($cList3) & ')' & @CRLF) EndSwitch EndSwitch EndSwitch Sleep(10) WEnd Func WM_COMMAND($hWnd, $iMsg, $wParam, $lParam) #forceref $hWnd, $iMsg Local $iCtrlID = BitAND($wParam, 0xFFFF) ; Low Word Local $iNotificationCode = BitShift($wParam, 16) ; Hi Word Switch $lParam ; Control handle Case $hList1, $hList2, $hList3 GUICtrlSendToDummy($cDummy, $iCtrlID & '|' & $iNotificationCode) EndSwitch Return 'GUI_RUNDEFMSG' ; GUI_RUNDEFMSG EndFunc1 point -
Double click on an item in a list
littlebigman reacted to Andreik for a topic
WM_NOTIFY is a code sent by a control to its parent window when an event has occurred or the control requires some information, so accordingly wParam will contain identifier of the control sending the message and lParam is a pointer to a NMHDR structure that contains additional information. WM_COMMAND is a code sent when the user selects a command item from a menu, when a control sends a notification message to its parent window, or when an accelerator keystroke is translate, so accordingly when the message is sent by a control wParam high word will contain the control-defined notification code, wParam low word will contain the control identifier and lPara will contain the handle to the control window. There is no better, each is used when it's appropriate. If you are interested just to know when a control is click, both can give you the answer but is you are looking for additional information WM_NOTIFY will provide such details.1 point -
If you compile from SciTE just add this directive in the beginning of the script. #AutoIt3Wrapper_Change2CUI=y PS: In compiled scripts you don't need to use | more and you are not enforced to use CRLF to output the console buffer.1 point
-
#include <Array.au3> $sTxt = 'echo $?' & @CRLF $sTxt &= '[?2004l' & @CRLF $sTxt &= '0' & @CRLF $sTxt &= '[?2004hroot@2aa7e32f703e:/# ' _ArrayDisplay(StringSplit($sTxt, @CRLF, 3)) ConsoleWrite(StringSplit($sTxt, @CRLF, 3)[2] & @CRLF) _ArrayDisplay(StringRegExp($sTxt, '(?m).+', 3)) ConsoleWrite(StringRegExp($sTxt, '(?m).+', 3)[2] & @CRLF) Two ways using native functions.1 point
-
What do you mean by each string? Give us exactly the text that you have in AutoIt variable and what part are you interested to get.1 point
-
If I get it right #include <String.au3> #include <Array.au3> Local $sTxt = "" $sTxt &= "$buf_collect=echo $?" & @CRLF $sTxt &= "0" & @CRLF $sTxt &= "]0;root@ivgl9:~[root@ivgl9 ~]# " Local $aArray1 = _StringExplode($sTxt, @LF, 0) _ArrayDisplay($aArray1, "_StringExplode") $aArray1 = StringSplit($sTxt, @LF, 1) _ArrayDisplay($aArray1, "StringSplit")1 point
-
Double click on an item in a list
littlebigman reacted to Jos for a topic
Ok then I won't complain anymore and simply lock it. ... but I did create a new topic for you this time!1 point -
Although serial ports are disappearing, they can still be useful. Here is a COMMs UDF. It provides an easy way to use serial ports without the restrictions and problems some methods have. USB to serial is ok, binary data is ok. This UDF requires my comMG.dll which can be in either the script folder or the Windows folder by default, or in the path specified using the function _CommSetDllPath. Note the following shortcomings: the dll link below is 32 bit so it will not work with a 64 bit apps, but there is a 64 bit version in my post around 25th March 2018 for people to try. The strings and character functions are all AnsiChar. Functions in the UDF are _CommVersion _CommListPorts _CommSetPort _CommPortConnection _CommClearOutputBuffer _CommClearInputBuffer _CommGetInputcount _CommGetOutputcount _CommSendString _CommGetString _CommGetLine _CommReadByte _CommReadChar _CommSendByte _CommSendBreak; not tested!!!!!!!!!! _CommCloseport _CommSwitch _CommReadByteArray _CommSendByteArray _CommsetTimeouts _CommSetXonXoffProperties _CommSetRTS (NB these will not work if Hardware handshaking is selected because _CommSetDTR then these lines are controlled by the data being sent.) _CommSetDllPath _CommGetLineStates -------------------------------------------------------------------------------------------------------------------------------- Go to Download Page For Commgv2 Download includes the dll and udf. Most recent changes 28th March 2014 - dll V2.83 Correct error setting 6 data bits as 7. 11th March 2014 dll V2.82 Allow data bits of 4 to 8 instead of only 7 and 8. 19th August 2013 dll v2.81 removes some unwanted eroor message popups. Might not remove popups for some Windows versions. 27th September 2012 Correct error closing port. New version of UDF if V2.90, new dll is commg.dll V2.79. Thanks to tfabris. 18th January 2012 Corrected typo in UDF V 2.87, and uploaded as V2.88 Increased max baud allowed by the dll from 200000 to 256000. New version now V2.78 17th January 2012 Modified thesleep addition to _CommGetLine so that reading data is not slowed down. 14th January 2012 Corrected _CommReadByte in UDF. Added sleep(20) to while loop in _CommGetLine to reduce CPU usage 20th December 2011 UDF version 2.86. - Changed function GetByte so it returned the error string given by the dll. Dll version 2.77 - removed an unwanted erro message dialogue from GetByte function. (Thanks funkey) 4th December 2011 New dll and example versions. Dll function SetPort corrected because it was not using the parameters passed for DTR and RTS. The example was setting flow control incorrectly: the settings for hardware handshaking and XON./XOFF were reversed. 25th August 2011 corrected function _CommClosePort. Example corrected for setting parity and flow 22nd December 2013 (thanks to MichaelXMike) mgrefcommg CommgExample.au31 point
-
This UDF allows to set an events handler for Mouse device. The beginning... I searched for a way to disable the Mouse Primary click, and be able to call some function when the click event is received... Big thanks to amel27 for this one, i only organized the whole stuff to UDF style. Example: #include <GUIConstantsEx.au3> #include "MouseOnEvent.au3" HotKeySet("{ESC}", "_Quit") _Example_Intro() _Example_Limit_Window() Func _Example_Intro() MsgBox(64, "Attention!", "Let's set event function for mouse wheel *scrolling* up and down", 5) ;Set event function for mouse wheel *scrolling* up/down and primary button *down* action (call our function when the events recieved) _MouseSetOnEvent($MOUSE_WHEELSCROLLDOWN_EVENT, "_MouseWheel_Events") _MouseSetOnEvent($MOUSE_WHEELSCROLLUP_EVENT, "_MouseWheel_Events") _MouseSetOnEvent($MOUSE_PRIMARYDOWN_EVENT, "_MousePrimaryDown_Event") Sleep(3000) ;UnSet the events _MouseSetOnEvent($MOUSE_WHEELSCROLLDOWN_EVENT) _MouseSetOnEvent($MOUSE_WHEELSCROLLUP_EVENT) _MouseSetOnEvent($MOUSE_PRIMARYDOWN_EVENT) ToolTip("") MsgBox(64, "Attention!", "Now let's disable Secondary mouse button up action, and call our event function.", 5) _MouseSetOnEvent($MOUSE_SECONDARYUP_EVENT, "_MouseSecondaryUp_Event", 0, 1) Sleep(5000) _MouseSetOnEvent($MOUSE_SECONDARYUP_EVENT) ToolTip("") EndFunc Func _Example_Limit_Window() Local $hGUI = GUICreate("MouseOnEvent UDF Example - Restrict events on specific window") GUICtrlCreateLabel("Try to click on that specific GUI window", 40, 40, 300, 30) GUICtrlSetFont(-1, 12, 800) GUICtrlCreateLabel("Press <ESC> to exit", 10, 10) GUISetState() _MouseSetOnEvent($MOUSE_PRIMARYDOWN_EVENT, "_MousePrimaryDown_Event", $hGUI) ;A little(?) bugie when you mix different events :( ;_MouseSetOnEvent($MOUSE_SECONDARYUP_EVENT, "_MouseSecondaryUp_Event", $hGUI) While 1 Switch GUIGetMsg() Case $GUI_EVENT_CLOSE ExitLoop Case $GUI_EVENT_PRIMARYDOWN MsgBox(0, "", "Should not be shown ;)") EndSwitch WEnd _MouseSetOnEvent($MOUSE_PRIMARYDOWN_EVENT) ;_MouseSetOnEvent($MOUSE_SECONDARYUP_EVENT) EndFunc Func _MouseWheel_Events($iEvent) Switch $iEvent Case $MOUSE_WHEELSCROLLDOWN_EVENT ToolTip("Wheel Mouse Button (scrolling) DOWN Blocked") Case $MOUSE_WHEELSCROLLUP_EVENT ToolTip("Wheel Mouse Button (scrolling) UP Blocked") EndSwitch Return $MOE_BLOCKDEFPROC ;Block EndFunc Func _MousePrimaryDown_Event() ToolTip("Primary Mouse Button Down Blocked") Return $MOE_BLOCKDEFPROC ;Block EndFunc Func _MouseSecondaryUp_Event() ToolTip("Secondary Mouse Button Up Blocked") EndFunc Func _Quit() Exit EndFunc Available Events Constants: ------------------------------------------ CHANGELOG: Download: Attached: MouseOnEvent_2.4.zip Old version: MouseOnEvent.zip - v2.3 MouseOnEvent_2.1.zip MouseOnEvent_2.0.zip MouseOnEvent_UDF_1.9.zip MouseSetOnEvent_UDF_1.8.zip MouseSetOnEvent_UDF_1.7.zip MouseSetOnEvent_UDF_1.6.zip MouseSetOnEvent_UDF_1.5.zip MouseSetOnEvent_UDF_1.4.zip MouseSetOnEvent_UDF_1.3.zip Previous downloads: 146 + 200 + 804 MouseOnEvent.zip MouseOnEvent.zip1 point
-
Detect Double click on the main GUI
KeeperOfTheReaper reacted to Authenticity for a topic
#include <GUIConstantsEx.au3> #include <WindowsConstants.au3> If Not IsDeclared("WM_LBUTTONDOWN") Then Global Const $WM_LBUTTONDOWN = 0x0201 If Not IsDeclared("WM_LBUTTONDBLCLK") Then Global Const $WM_LBUTTONDBLCLK = 0x0203 If Not IsDeclared("GCL_STYLE") Then Global Const $GCL_STYLE = -26 Local $fDblClk = False Local $iDoubleClickTime = 200 ; _WinAPI_GetDoubleClickTime() ; 500 by default Local $hGUI = GUICreate("Test", 300, 300) GUIRegisterMsg($WM_LBUTTONDBLCLK, "_WM_LBUTTONDBLCLK") GUIRegisterMsg($WM_LBUTTONDOWN, "_WM_LBUTTONDOWN") GUISetState () Do Until GUIGetMsg() = $GUI_EVENT_CLOSE GUIDelete() Exit Func _WM_LBUTTONDBLCLK($hWnd, $iMsg, $iwParam, $ilParam) Local $iX = BitAND($ilParam, 0xFFFF), $iY = BitShift($ilParam, 16) $fDblClk = True ConsoleWrite("!Double click on: [" & $iX & "," & $iY & "]" & @CRLF) Return $GUI_RUNDEFMSG EndFunc Func _WM_LBUTTONDOWN($hWnd, $iMsg, $iwParam, $ilParam) Local $iX = BitAND($ilParam, 0xFFFF), $iY = BitShift($ilParam, 16) Sleep($iDoubleClickTime) If $fDblClk Then $fDblClk = False Return 0 EndIf ConsoleWrite("+Single click on: [" & $iX & "," & $iY & "]" & @CRLF) Return $GUI_RUNDEFMSG EndFunc Func _WinAPI_GetDoubleClickTime() Local $aResult = DllCall("user32.dll", "uint", "GetDoubleClickTime") Return $aResult[0] EndFunc1 point -
Was waiting for chicken to cook, so I combined them for you: #RequireAdmin If DisplayChangeRes(1920, 1080, 32, 60) = 0 Then MsgBox(0, "Error", "Invalid resolution selected") Func DisplayChangeRes($WIDTH, $HEIGHT, $BPP, $FREQ) If CheckDisplay($WIDTH, $HEIGHT, $BPP, $FREQ) = 0 Then Return 0 EndIf $DM_PELSWIDTH = 0x00080000 $DM_PELSHEIGHT = 0x00100000 $DM_BITSPERPEL = 0x00040000 $DM_DISPLAYFREQUENCY = 0x00400000 $CDS_TEST = 0x00000002 $CDS_UPDATEREGISTRY = 0x00000001 $DISP_CHANGE_RESTART = 1 $DISP_CHANGE_SUCCESSFUL = 0 $HWND_BROADCAST = 0xffff $WM_DISPLAYCHANGE = 0x007E $DEVMODE = DllStructCreate("byte[32];int[10];byte[32];int[6]") $B = DllCall("user32.dll", "int", "EnumDisplaySettings", "ptr", 0, "long", 0, "ptr", DllStructGetPtr($DEVMODE)) If @error Then $B = 0 Else $B = $B[0] EndIf If $B <> 0 Then DllStructSetData($DEVMODE, 2, BitOR($DM_PELSWIDTH, $DM_PELSHEIGHT, $DM_BITSPERPEL, $DM_DISPLAYFREQUENCY), 5) DllStructSetData($DEVMODE, 4, $WIDTH, 2) DllStructSetData($DEVMODE, 4, $HEIGHT, 3) DllStructSetData($DEVMODE, 4, $BPP, 1) DllStructSetData($DEVMODE, 4, $FREQ, 5) $B = DllCall("user32.dll", "int", "ChangeDisplaySettings", "ptr", DllStructGetPtr($DEVMODE), "int", $CDS_TEST) If @error Then $B = -1 Else $B = $B[0] EndIf Select Case $B = $DISP_CHANGE_RESTART $DEVMODE = "" Return 2 Case $B = $DISP_CHANGE_SUCCESSFUL DllCall("user32.dll", "int", "ChangeDisplaySettings", "ptr", DllStructGetPtr($DEVMODE), "int", $CDS_UPDATEREGISTRY) DllCall("user32.dll", "int", "SendMessage", "hwnd", $HWND_BROADCAST, "int", $WM_DISPLAYCHANGE, _ "int", $BPP, "int", $HEIGHT * 2 ^ 16 + $WIDTH) $DEVMODE = "" Return 1 Case Else $DEVMODE = "" Return $B EndSelect EndIf Return 1 EndFunc ;==>DisplayChangeRes Func CheckDisplay($w, $h, $bit, $f) $flag = 0 $wbemFlagReturnImmediately = 0x10 $wbemFlagForwardOnly = 0x20 $colItems = "" $strComputer = "localhost" $objWMIService = ObjGet("winmgmts:\\" & $strComputer & "\") $colItems = $objWMIService.ExecQuery("SELECT * FROM CIM_VideoControllerResolution", "WQL", _ $wbemFlagReturnImmediately + $wbemFlagForwardOnly) If IsObj($colItems) Then For $objItem In $colItems If $w = $objItem.HorizontalResolution And $h = $objItem.VerticalResolution And 2^$bit = $objItem.NumberOfColors And $f = $objItem.RefreshRate Then $flag = 1 Next EndIf Return $flag EndFunc ;==>CheckDisplay1 point
-
From a request in the support forum. If you have only one button, you can send $sCIDChange just the text you want to change it to, or if your using more than one button, you can send it an array in the order you want the buttons to be changed to the text you want to change them. Local $ChangeText[4] = ['', 'Enable', 'Disable', 'Quit'] $iMsg = _MsgBoxEx(3, 'nothing', 'something', 0, $ChangeText) MsgBox(64, 'Info', 'The Return Was: ' & $iMsg) Func _MsgBoxEx($iFlag, $sTitle, $sText, $iTime = 0, $sCIDChange = '') Local $_MsgBox_ = '"' & "ConsoleWrite(MsgBox(" & $iFlag & ', ""' & $sTitle & '"", ""' & $sText & '"", ' & $iTime & '"))' Local $iPID = Run(@AutoItExe & ' /AutoIt3ExecuteLine ' & $_MsgBox_, '', @SW_SHOW, 6) Do Sleep(10) Until WinExists($sTitle) If IsArray($sCIDChange) Then For $iCC = 1 To UBound($sCIDChange) - 1 ControlSetText($sTitle, '', 'Button' & $iCC, $sCIDChange[$iCC]) Next Else ControlSetText($sTitle, '', 'Button1', $sCIDChange) EndIf While ProcessExists($iPID) Local $iStdOut = StdoutRead($iPID) If Number($iStdOut) Then Return $iStdOut Sleep(10) WEnd If IsArray($sCIDChange) Then Return SetError(1, 0, 2) Return SetError(1, 0, 1) EndFunc Edit: Suggestion on time out from MHz1 point
-
FireFox help
JLogan3o13 reacted to TheDcoder for a topic
@FinDaPancake First off, make sure that you are familiar with the fundamentals of AutoIt, I'm saying that since you seem to lack the knowledge regarding the concept of UDFs (user-defined functions). I'm not really sure what the right resource is for learning all the fundamentals so I request others to share their resources. The one resource you can always count on is the help-file, but it might be too verbose for someone who is not from a highly technical background. Also tagging @water here, the one who started the wiki article, since OP seems to be having a hard time with it.0 points